I agree entirely - functional approaches tend to result in much more elegant code, where suitable.

That looks very similar to Rust's match construct, which is basically the same thing but with C-style syntax. Another useful feature I've seen (that would be incompatible with Python's preference for duck typing) is D's final switch, which ensures that cases exist for all members of an enum.

Allowing others to use the same frequencies in a compatible manner would achieve the same benefits (improved coverage, since anyone can operate a tower) without the fragmentation. Not to mention that the cost of negotiating spectrum rights in each state/area would be significant, to say nothing of the fun issues that crop up along boundaries.

You have now added a second antenna to the device, increasing power consumption and complexity, not to mention the additional logic needed to decode the messages.

While I could be wrong, I'm pretty sure the norm is to have different antennas for most of those. Bluetooth and wifi can share one as they use the same frequency, but 2.4 GHz is so far from 900/1800/2100 MHz that it would definitely need a separate antenna. Even making an antenna with the desired characteristics at 3 discrete frequencies likely increases the cost significantly - covering a continuous range of frequencies like that without degrading reception would be even harder.

Your idea is interesting, but ultimately overcomplicated. The entire thing is basically a hack to deal with the fragmentation introduced, but it appears to me your real problem is that the current system grants a monopoly over the frequency. This would be addressed in my proposal by mandating that anyone can use the frequency, provided they were compliant with the protocol and associated regulations. (Or to put it differently, the spectrum would be allocated to protocols, rather than corporations.) It's not clear at all what advantages your approach brings over this.

The problem with this rule is that it means limiting your feature-set so that you have N features with clearly defined regions of use, instead of 2N features with overlapping use cases. Switch statements are one example of this - they've been around since C (or possibly earlier) because they're clearer than a massive if-elseif-etc. statement, but Python lacks them, and people sometimes try to hack something similar into existence using dictionaries of lambdas.

Another is Python supports both functional and imperative programming, which means there's inherently two different ways of performing many simple tasks. Obviously many other languages chose only one of these, and Python is clearly more powerful for having both, but it's a good example of how having more than one way to do things results in a more expressive language.

I disagree completely - I think the issue you're dealing with is that the kernel is not written in C++, and its style reflects that. The kernel is one of the best written pieces of C I've seen, easily better than an average C++ project. IMO, the only feature that the kernel would really benefit from is templates (for added type safety) - everything else works fine.

Furthermore, your argument about things being automatic in C++ is exactly the reason why most kernel developers use C instead! When you are writing a kernel, you absolutely do not want anything happening implicitly - it needs to be explicit, otherwise it's going to cause problems because it's not going to be obvious when it's interacting with something else. To give you an example, it's possible code in the block I/O subsystem to get stuck in an infinite loop upon allocating memory, since that request can result in paging, which results in disk operations via the block I/O subsystem, etc.

Context: I have experience doing both kernel programming (in C) and application development (in C++ with Qt). I think C++ is a powerful language which can lead to some rather beautiful code when used with Qt. I also think that C makes it far too easy to write bad code (buffer overflows, null terminated strings, needing to check return codes without defining a consistent scheme for whether 0 is success or failure, etc.). For any other project, I'd go with C++ in a heartbeat (or maybe D, depending on what libraries I needed). But in the context of kernel development, C++ is definitely the wrong tool for the job.

For two reasons. The first is that in the majority of cases, depression tends to be the result of environmental factors, as opposed to genetic ones. The second is that many people who struggle with depression often have a lot to contribute to society, particularly as it is known to correlate with creativity.

While I agree with your general point, I'm not convinced its possible to remove all quick and easy suicide methods. For example, electrocution seems like an easily accessible one, especially if you insert some paperclips into the socket and touch your chest to them. Admittedly, it would require some creativity, but it's not something that can be easily prevented. (RCDs help, unless the person has isolated themselves from the floor.)

The big problem I see with this is the fragmentation it would cause. Quite frankly, the US already has issues due to their major mobile phone networks using different frequencies. Having different frequencies for the same network, within the same country would just exacerbate that.

I would argue that where the frequency is used for a standardized protocol, they should be required to allow others to use it, providing they are compliant with the appropriate standard. Allowing other frequencies to be allocated for competing standards would only be permitted where there were clear benefits to doing so.

Why would he? Wine runs as an unprivileged user - the only reason he might have needed root access is to open one of the privileged ports.

I think this is only part of it. I grew up using Windows (and am consequently lost on Macs), but I found Linux easier to learn than Windows. This may be partly due to my technical inclinations, but I think that variations in usability and documentation can make a real difference to how easily you can learn to use a system.

Given that this is Debian we're talking about, the the right comparison is with an LTS kernel, not a stable one. 3.17 is already EOL, and it was only released in October. The most recent LTS kernel is 3.14.

That said, Jessie is currently running 3.16, so there's likely something I'm unaware of regarding Debian's kernel policy...

The change is an improvement to sandboxing (i.e. security). If the kernel patch was sufficiently minor (this appears to be the case), it makes far more sense to backport it (improving the security under older kernels) than to remove it (compromising security under newer kernels). This is especially true given Debian's focus on security.

Most of the comments in the thread seem to be from people who don't care, but are happy to use it as an opportunity to bash Chrome/Chromium. I suspect if someone had actually done the work of writing a patch, it would have been merged without much drama.

While I agree that it's questionable whether systemd is suitable for Debian stable, I would hardly describe it as resulting from "dirty politics".
The reason that systemd got adopted is very simple: it means less work for distro maintainers. Systemd .service files are much easier to maintain than initscripts, systemd comes with logind (consolekit is unmaintained, and no one is interested in picking it up), and perhaps most importantly, Red Hat is pushing it (which means that they would contribute significantly to porting programs to it. The only real alternative to it was OpenRC, which doesn't fix the consolekit issue.[1] The maintainers were the ones making the decision, so they put their interests first, as opposed to that of their users.

I agree that systemd has some architectural issues (just cause you choose a binary log format, doesn't mean you need modify the start of it on each update) and management issues (it should never have assimilated udev without continuing to support its use without the rest of systemd), but its adoption was entirely due to the opportunity cost of choosing anything else, as opposed to politics.

[1] For the record, I think that OpenRC would have been a fine alternative for Debian. While it doesn't have as much upstream development, it doesn't need to as it's a mature product.

I've been using Sabayon for a few years now - it's a nice combination of some fairly nice features (being able to mix entropy and portage, Gentoo-style config file management, fairly bleeding edge packages) and making other things just work (bumblebee, UEFI). I agree that the documentation is a bit weak (downside of a small community), but in practice the only difference from Gentoo is the package manager and default config. (The Arch wiki is also quite useful.)

SystemD works pretty well once you get the hang of it, and these days pretty much everything supports it. Most of the criticisms of are concerning its architecture and management, rather than functional problems. (I think the most significant bug I've seen with it in the last year or two is that systemd-journald needs to be manually restarted if your rootfs gets full, which is fairly minor as bugs go.)

I suggest making backups of your root file system (btrfs snapshots are perfect for this) before updates though - I've had a major regression about once a year, on average. (To be fair, one of them was due to me doing something very unsupported with glibc, and the other due to some somewhat uncommon hardware. Both were fixed within a week as well.)

Feel free to reply to this post with any questions you might have about it. It definitely doesn't get as much attention as it merits, IMO, so I'm always happy to help out people who are interested in it.

More importantly, slashdot.jp can handle it too. It's probably trivial to port the code across - I'm surprised no one has done it.

Their APU lines are pretty nice. Their FX line was great 3 years ago (much better performance/price ratio than Intel), but it hasn't gotten any significant upgrades since then.