weland

There are!

http://www.emacswiki.org/emacs/CategoryMail

Don't get me wrong, I think GitHub's move is retarded.

It's just that no one has a right to whine about it any more than they have a right to whine about what their retarded neighbour does in their apartment. If your retarded neighbour has a "no cursing" policies in their home, you can either not be his guest, or not swear while in his house. Either way, it's his right.

There are two possibilities:

* Either this is not OK for Open Source, and it will prompt people to move away from GitHub -- because, sure, we needed the INT_MAXth reminder that relying on a private third-party for a free service is a bad idea, or

* This is something most open source projects have no problem with, and they'll just keep going, while leaving open source "radicals" like you and me to whine about it.

Github didn't just magically become this super important center for open source work. It's an important center for the open source world because a lot of people are using it.

It can stop being an important center, that's not a problem.

> Who decides what is and is not appropriate?

GitHub, because that stuff is hosted on their servers.

This is not about Open Source. This is about GitHub.

Yes, it has no place in Open Source. Whether or not it has a place on GitHub is, however, up to GitHub itself.

No, just make sure the web's big shot at peer-to-peer networking doesn't poke yet another hole in the already shabby privacy of today's average web user.

I won't even go into the debate of whether or not we want "the web" to be the support for the p2p network of the future.

> Peer-to-peer networking is the web's big chance to weaken these huge personal data-scarfing companies.

On the other hand, this particular problem is another ace in the hands of those huge personal data-scarfing companies.

The hardest bug I ever tracked to date resulted from a combination of me being a n00b at the time and legitimately being hard. It was a stack thrashing bug on an RTOS that ran on a system without MMU. To make things a little worse, GCC support for that platform was still very early at the time, so GDB would occasionally become confused, and did not support watches; besides, everything had gotten big enough at the time that there was no way to compile the whole system with debug symbols and no optimizations; the image was stripped and optimized for size.

The bug wasn't easy to reproduce: all we saw was that, every once in a while, when queried over $wirelessprotocol, the system would begin answering with crap values (it was supposed to measure some physical quantities, and crap values = meaningless, as in negative active power and hundreds of kV on a mains line), and if you kept on pounding it, it would eventually start "acting funny" -- randomly toggling LEDs and handling commands that were never given in the first place -- before eventually crashing. The problem was very far removed from its core; at first, all I was debugging was "system begins answering with thrashed values after a while".

I was two days into it when a more experienced colleague (I was a junior developer at the time) stepped in to help me. We began suspecting a process was smashing another process' stack when, after removing module after module, the bug was still not clearly reproducible by a particular sequence of steps, but the behaviour it triggered became fairly uniform.

We decided a good way to test this assumption was to modify the context switching routine to dump the current top of the stack over a serial line; unfortunately, that introduced additional delays that prevented the bug from occurring, so it didn't help us. We figured, however, that the handler for $wirelessprotocol's query was in the process that smashed the other process' stack, so we modified that handler to send the top of the stack over wireless (this is where not having a MMU helped, ironically :-) ). The base of the other process' stack could be obtained by just tracing context switches.

Sure enough, if enough commands piled up, that process (which was running some pretty intensive stuff, including floating point operations, on a very resource-constrained system) would smash into the next one's stack, messing up its context's registers.

In retrospect, this wasn't necessarily a difficult bug per se: the concept is well-understood and the theory behind it is trivial. The biggest problem is that it challenges the fundamental way we debug programs: when the CPU starts doing crap, we assume we've instructed it to do crap, and it's (correctly!) following consistently bad instructions. In this case, the CPU ended up following random instructions.

It would probably be OK if all programs have a simple, predictable sequence of malloc and free that they call in a loop, with similar-ish sizes each time.

It's extremely unpleasant to program something with just a few KB of RAM and not know exactly what memory goes where. However, a lot of IoT-related gadgets just gather a buffer of data from an ADC or something, average it and send it over some wireless protocol every 1 minute. The allocation pattern is predictable enough that you don't run into strange cornercases.

I see no reason why anyone would want to use this commercially, but for the enthusiast market (and maybe even for some rapid prototyping) this looks interesting enough.

I have written code while high, which has convinced me that the expression "Man, the dude who wrote this must have been high" is worth its derogatory tone.

What does being open source have to do with having crap policies?

There are plenty of open source projects that don't have those problems, and it's not like the core team is interested in making theming anything else but a clunky hack so that everyone uses Adwaita...

Do a google search for GTK 3.16 theme bug. You'll find a bunch of people for whom it didn't take minutes.

Bullshit. Every time a new GTK3 release comes up, the bug trackers of popular themes flare up (many of them obscure, e.g. https://github.com/shimmerproject/Numix/issues/206), various undocumented tidbits and bugs in the theming engine pop up and "innovations" like the client-side decorations are introduced.

Meantime, clunky, terrible C modules written back when GTK 2.10 was a thing work just fine on 2.99.

That is not simplification. Simplification is when things get easier, not when they get harder.

Thanks! I'll keep that in mind for when I run out of choices and have to upgrade :).

I also get GTK2 for free. That's not the problem. I'd happily make my own GTK3 theme if GTK3 weren't so incredibly hostile to theme development. It's literally less reliable than Windows Blinds, which is a frickin' hack on top of a closed OS.

It's not a problem of asshole theme creators, it's a software quality problem, and everyone in the Gnome Project's bubble is dancing around it and pretending it's good for the users.

> Or most of them probably just gave up making GTK themes.

Yeah, things are pretty terrible for theme developers. It's like GTK 3 development was steered by Steve Ballmer.

> Honestly I haven't seen anything GTK+ based that looks as good as KDE (4.x).

Here's a phrase I never thought I'd heard :-).

I don't really like Greybird, but Bluebird is nice. Now if only there were a (non-hacky) way to consistently disable the frickin' client-side decorations, I could almost use Gnome 3.

Yeah, but the backend seems to be buggy, the documentation is not up-to-date and basically half the things that work in 3.x break mysteriously in 3.(x + 1).

Meanwhile I can use a gtk2 theme from 2006 without any problems (and it doesn't make my desktop look like a kid's HD drawing). As long as I can do that, I have very little motivation to put up with gtk3's crap.

Yeah. I still manage to live in a gtk2-only world for now, but mostly because I don't really need too many GUI programs (I can't remember the last time I opened something other than Thunderbird, Firefox, Emacs, and whatever pdf reader and image viewer I have lying around) but that's obviously not sustainable.

Unfortunately, GTK3 (and, for that matter, much of the modern Linux user-side development ecosystem) is increasingly hostile. Frequent, often unwarranted changes (implemented through code of dubious quality), crap documentation (when it exists). It feels increasingly like developing for (and using) OS X or Windows, just without the good parts that we all secretly covet, like Visual Studio and Interface Builder and the MSDN.

I was prepared to whine about exactly that.

There is literally no gtk3 theme that, simultaneously:

- Is not flat and generally grey or dark blue. It's as if everyone Apple fanboy who was rejected by Apple's UX department is now making GTK themes.

- Is not frickin' ginormous. I know multitasking is frowned upon now that we have tablets, but I have a bloody 27" screen, I want more than one window on it at the same time!

- Doesn't break in the next release.

At first (as in, 2011 or so) I just blamed it on gtk3 being new and all that. But we're four years from that. This disaster seems to be intentional.

I think the formula that Wikipedia gives isn't used that often for most exoplanets. Oftentimes all you know about a planet is the mass, radius and some information about temperature or at least energy flux to its surface, so they use those at first.

I guess the parameters were chosen by some curve fitting procedure to make sure it gives 1.0 for Earth, 0.7-ish for Mars, 0.2 for Uranus and Neptune which are basically the most "not like the others" in our solar system and so on. It's not really a measure of habitability or anything like that. "Equalizing the parameters' meanings" presumably has to do with mapping their relative variation (and the effects of that variation over various observable parameters) over a smaller range.

It's a reasonable measure of surface gravity, which, along with an idea about the distance from the star it's orbiting, gives us a good idea about what kind of atmosphere we can expect (i.e. the lighter and the hotter a gas is, the easier it can escape a planet with a particular escape velocity), at least a basic idea about what kind of surface features we might expect and so on.

It's also a parameter that is quick to compute starting from radius and mass, which are often the first things you know about an exoplanet due to the way they're found.

I've worked for a small company and we had similar problems. It's not that you have to convince six layers of bureaucrats who have no idea what GPL is but they read in eWeek that it's scary -- it's simply that, when you're that small, long-winded consulting services from IP lawyers is not the kind of stuff you want to spend money on.

What you're describing is security by obscurity, and it has been shown countless times that it never, ever works.

It does not prevent flaws from being discovered. It slows down the discovery of some flaws, but this also means that the people who discover them can exploit them for years if they're malicious, because flaws are equally hard to discover as part of a well-intentioned an audit as they are as part of an evil plan.

It also allows flaws that have been intentionally introduced to be hidden from sight for a long time -- and allows companies who do so to escape untarnished; since the commit logs are not available (and the source code is often only available in disassembled form), they can always claim it's a bug, not a feature.

It does not provide additional safety, it provides only an illusion of safety -- while making actual safety a lot harder to implement, for everyone.

> a house of cards built on poor memory management :-/.

Shit, this is the most accurate description of modern software that I've seen so far.

> Q: What is the relative efficiency of the two systems? > A: I don’t really care for this proof of concept.

Looks like he'll have a ton of fun after this proof of concept...

Most software that's as complex as Flash is probably similarly full of bugs. Most of those vulnerabilities reek of huge development teams toiling over a codebase whose foundation was written in the late 90s and had features and fixes duct taped ever since.

There was plenty of high-quality content before tracking user became something worth paying for.

Being able to track users pays for most of the crap content on the Internet -- much of which is there to support tracking users, not the other way 'round.

It can go the way of the dodo as far as I'm concerned.

> Why is reading plain text out of /dev/mouse and writing plain text to /dev/draw an improvement over how Linux or OS X or Windows does it?

It's very useful because uou don't need a C FFI to access OS functionality, graphics libraries and the like. Any language whose implementation allows you to read and write files can already do a lot of things (including GUIs, IPC and so on). There are very few wheels to reinvent. Furthermore, any program that wants to integrate with yours also needs to do nothing other than open, read, write and close files. You can expose any function or configuration variable of your programs through files -- and all you need to do for that is to read and write byte or UTF-8 streams.

Things go a bit further than just "IPC is done by reading and writing files". It's only one of the principles behind Plan 9's approach to files and filesystems.

App developers who are as big in application consumption as Taylor Swift is in music would get the same treatment.

The usual reason is #3. You're only willing to pay shit and instead of compensating for that with actually useful things, you're selling philosophy and crap like "company culture", as if a company that's not at least 15 years old can have that.

The reasons you listed are all nice, but most of the people who do it are doing it for reasons like #3 above. You risk ending up in the same pot as they do.

I see a lot of positive reactions to how happy we should be that science changes. I mean, look how long it took us to get out of the dark ages, right?

But no, the liberality of changes like this one is what separates fluff science from actual science. There is a vast chasm of difference between stuff like this one and, say, aether theories.

People who came up with aether theories were the brightest of their ages. That is really the best they could come up with -- and the reason why it took us so long to disprove aether-based theories was that they had some bloody solid science behind them -- at least back in those ages. People were unable to come up with anything better because, for a very long time, they lacked both theoretical and experimental tools with which to conclusively prove (or disprove) their hypotheses.

We needed significant developments in mathematics, fluid mechanics and optics in order to test these theories, and we needed special relativity to come up with something better.

Whereas claims like the one this article refutes need only a correct application of double-blind testing and not falling into well-known (at least to statisticians) traps in order to be tested.

The fact that we have 180 degree spins in understanding such matters every six months is not a testament to how modern science cares only about truth. It's a testament of how important it is to publish papers.