Either commit to 100 percent coverage or accept that areas you're not providing service for should be able to use frequencies there that you use in other places but not there.
There's no reason to give someone that kind of blanket lease.
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.
What is more, the fragmentation is a technological problem that is quiet easily addressed.
First, we can have catalog frequency. That is one frequency EVERYWHERE that specifies what frequencies other services are using in the area. As your device moves it will periodically listen to that frequency and update its database for that area as to what is used by what. This ensures that every device will at least be aware of what frequencies are in use and by what.
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.
Second, the next technological problem is making your device adaptable enough that it can shift to different frequencies and possibly even different protocols. Most devices already do this especially smartphones. My smartphone has a bluetooth radio, a wifi radio, an FM receiver, a GPS receiver, a 2G radio, a 3G radio, and a 4G radio. I think it can also handle either CDMA or GSM. So that is already a very wide range of frequencies and many different protocols.
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.
There should be one-- and preferably only one --obvious way to do it.
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.
The problem with C++ is that it's way too easy to write write-only code, because the language has so many features that nobody but language experts understand all of them. So we all program in different dialects, and then scratch our heads when we read other peoples' code.
Less so than C, especially as used in the kernel. Seriously read some of the Linux kernel and compare it with any good C++ project. The kernel loses BADLY. The manually implemented virtual classes are not pretty and not type safe, and neither are all the ugly macros needed to do things that would safe, automatic and easy to read in C++.
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 leases on spectrum should be specific to the region like conventional radio stations. If I lease a bit of spectrum in Florida for a radio station, I don't own that same frequency in California. I don't even own it in all of Florida.
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.
It's what you learn on. I learned on Windows, when I use a Mac I'm utterly lost and think "Why did Apple make it so hard to find anything?"
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.
The application dropped support for production kernels... because it wants a patch that isn't yet in production kernels.
The feature is in several stable kernel branches. Your distro might just not support them, so either don't use Chrome, or don't use that distro, or figure out how to use a newer kernel on your distro.:)
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...
This doesn't pass the sniff test. This 'bug' has apparently been around for months (October/November) and it's just now that people are noticing? And the fix is patching the kernel rather than regressing whatever change was in Chrome that added this?
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.
Systemd was forced upon Debian users thanks to some dirty politics, and has generally been unwanted by most of the Debian community.
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.
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.
The file command (which uses/etc/magic) works fine, but the mimetype command will defer to the file extension unless the --magic-only flag is passed. Most DEs use the mimetype command, since the output is easier to work with.
Incorporating Mali GPUs is bound to piss off the OSS crowd - they tried that before with PowerVR before, and those chips were the bane of any nettop user. They should have tried to slim down their own GT chips.
Perhaps, but I suspect Intel could more than balance it out by adding a few developers to the Lima project.
Nobody I know is using G+.. and everybody I know is using facebook, in all age groups - including my whole family(between age 7 to 66) that I like keeping in touch with. Many people abandoned all other styles of communication (emails, IMs) and just use facebook and fb messenger. Until Google get's all those people to use G+.. I for one am not interested, because the point is to 'connect' with people and G+ don't have any.
It's not an either-or. I use FB for keeping up with friends and family (i.e. people I know in real life), but G+ is a far better platform for following hobbyist groups (e.g. distro pages) and celebrities (e.g. Linus Torvalds), because it allows non-reciprocal connections. That is, I can follow Torvalds' public posts without him needing to follow me.
When you have to work with this stuff, in the end you realize that it is mostly about what was best for the team at the time they started the project (availabe skillset, docs, etc) and at this point both frameworks are the best the open source world has to offer.
Which means that the most useful data points are the projects which went through the effort of migrating between libraries. e.g. Subsurface which moved from GTK+ to Qt, and written by Linus Torvalds (among others). The reasons for doing so are given here. This is particularly interesting given that both Linus and Dirk prefer C
In my experience, the Qt libraries and tools are just as easy to use as.NET Framework + Visual Studio, which I think is excellent (and particularly impressive, given that Qt definitely doesn't have the same resources as Microsoft). I haven't used GTK+, but looking at the Hello World tutorial for it, it doesn't seem particularly intuitive. (e.g. why is the button label set with a callback?) Admittedly, there is some bias due to familiarity here, but I think my point is valid.
Easy way to find out: Mega could file a tortious inteference suit, and subpoena Paypal for the details. If it was one of the major processors, it'll be revealed and they can avail themselves of damages. If it was an NSL, that will become apparent too.
They are the best. Old laws were written way before all of the 'politics' which happens today.
There were politics back then too, it's just that the money was in different industries.
New laws are complex, and complexity is fraud. Some old laws are wrong, and have been thrown out, but if the longer the law has survived the better it is.
I'm not sure if it's the same study, but the 25-hour rhythm is addressed in the article:
But Charles Czeisler, a professor of sleep medicine at Harvard and chief of the Division of Sleep Medicine at Harvard’s Brigham and Women’s Hospital, discovered that the 1970s finding of a 25-hour natural circadian rhythm for humans was wrong. The original study allowed test subjects to turn on artificial light whenever they wished, unintentionally resetting their bodies’ circadian rhythms.
At about the time Pathfinder landed, Czeisler and his team began conducting studies at the hospital’s special laboratory that shielded study subjects from all outside influences. With their test subjects in isolation, they simulated the Martian sol to see how the test subjects adjusted to the longer day. “What we learned was none of the people adapted their circadian rhythms to the Martian day,” Czeisler said.
Yes, dumb users are unable to exercise choices meaningfully, especially if they are unaware they even have a choice. But that doesn't mean that choice doesn't exist, and can't be exercised by even somewhat competent users. Googling "ubuntu change desktop environment" returns easily followed instructions for doing so via the GUI, so the only requirements are knowing how to use google, and what a desktop environment is (if they don't know the latter, they could easily find out by posting on the forum, or asking whichever person told them to try Ubuntu in the first place).
DE-specific releases don't exist because they're the only way of installing a DE, they exist because most people want to have a DE out of the box, but disagree which one to have.
Gnome 2 was released in 2002, and supported at least until the release of Gnome 3 in 2011 (9 years). In contrast, the WinXP was current for 6 years, and the Vista interface for 5 years until Win8. KDE has had a major release every 6 years, comparable to Windows. Xfce has been on version 4 for 12 years. Additionally, KDE4 is still supported, as is Gnome 2 (under the MATE project). So by the numbers, the popular Linux DEs are at least as stable as Windows in terms of UI.
Now, if you want to argue that Linux is more fragmented in terms of UI because of this, that's a different discussion, but doing an apples to apples comparison shows that it is as stable/disruptive as Windows in the worst case (KDE), and significantly more stable in the other cases (Gnome and Xfce).
You can replace Gnome 3 with MATE or KDE without impairing your ability to run applications (you know, what you actually use the computer for). The same can't be said for replacing Windows.
I guess operating systems acquiring HiDPI support is one of the reasons going for the flat look. Vector graphics are easy to scale. But maybe some genius will eventually come up with a system that both scales well and looks cool.
KDE4 uses vector graphics for all of its icons, and none of them look 'flat' to me.Most of them have shadows, perspective, or some other kind of depth cue.
Slashdot Mirror
Either commit to 100 percent coverage or accept that areas you're not providing service for should be able to use frequencies there that you use in other places but not there.
There's no reason to give someone that kind of blanket lease.
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.
What is more, the fragmentation is a technological problem that is quiet easily addressed.
First, we can have catalog frequency. That is one frequency EVERYWHERE that specifies what frequencies other services are using in the area. As your device moves it will periodically listen to that frequency and update its database for that area as to what is used by what. This ensures that every device will at least be aware of what frequencies are in use and by what.
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.
Second, the next technological problem is making your device adaptable enough that it can shift to different frequencies and possibly even different protocols. Most devices already do this especially smartphones. My smartphone has a bluetooth radio, a wifi radio, an FM receiver, a GPS receiver, a 2G radio, a 3G radio, and a 4G radio. I think it can also handle either CDMA or GSM. So that is already a very wide range of frequencies and many different protocols.
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.
There should be one-- and preferably only one --obvious way to do it.
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.
The problem with C++ is that it's way too easy to write write-only code, because the language has so many features that nobody but language experts understand all of them. So we all program in different dialects, and then scratch our heads when we read other peoples' code.
Less so than C, especially as used in the kernel. Seriously read some of the Linux kernel and compare it with any good C++ project. The kernel loses BADLY. The manually implemented virtual classes are not pretty and not type safe, and neither are all the ugly macros needed to do things that would safe, automatic and easy to read in C++.
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 leases on spectrum should be specific to the region like conventional radio stations. If I lease a bit of spectrum in Florida for a radio station, I don't own that same frequency in California. I don't even own it in all of Florida.
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.
why "Windows makes it so hard to do stuff"
It's what you learn on. I learned on Windows, when I use a Mac I'm utterly lost and think "Why did Apple make it so hard to find anything?"
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.
The application dropped support for production kernels ... because it wants a patch that isn't yet in production kernels.
The feature is in several stable kernel branches. Your distro might just not support them, so either don't use Chrome, or don't use that distro, or figure out how to use a newer kernel on your distro. :)
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...
This doesn't pass the sniff test. This 'bug' has apparently been around for months (October/November) and it's just now that people are noticing? And the fix is patching the kernel rather than regressing whatever change was in Chrome that added this?
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.
Systemd was forced upon Debian users thanks to some dirty politics, and has generally been unwanted by most of the Debian community.
While I agree that it's questionable whether systemd is suitable for Debian stable, I would hardly describe it as resulting from "dirty politics". .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.
The reason that systemd got adopted is very simple: it means less work for distro maintainers. Systemd
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.
The file command (which uses /etc/magic) works fine, but the mimetype command will defer to the file extension unless the --magic-only flag is passed. Most DEs use the mimetype command, since the output is easier to work with.
Incorporating Mali GPUs is bound to piss off the OSS crowd - they tried that before with PowerVR before, and those chips were the bane of any nettop user. They should have tried to slim down their own GT chips.
Perhaps, but I suspect Intel could more than balance it out by adding a few developers to the Lima project.
Nobody I know is using G+.. and everybody I know is using facebook, in all age groups - including my whole family(between age 7 to 66) that I like keeping in touch with. Many people abandoned all other styles of communication (emails, IMs) and just use facebook and fb messenger. Until Google get's all those people to use G+ .. I for one am not interested, because the point is to 'connect' with people and G+ don't have any.
It's not an either-or. I use FB for keeping up with friends and family (i.e. people I know in real life), but G+ is a far better platform for following hobbyist groups (e.g. distro pages) and celebrities (e.g. Linus Torvalds), because it allows non-reciprocal connections. That is, I can follow Torvalds' public posts without him needing to follow me.
When you have to work with this stuff, in the end you realize that it is mostly about what was best for the team at the time they started the project (availabe skillset, docs, etc) and at this point both frameworks are the best the open source world has to offer.
Which means that the most useful data points are the projects which went through the effort of migrating between libraries. e.g. Subsurface which moved from GTK+ to Qt, and written by Linus Torvalds (among others). The reasons for doing so are given here. This is particularly interesting given that both Linus and Dirk prefer C
In my experience, the Qt libraries and tools are just as easy to use as .NET Framework + Visual Studio, which I think is excellent (and particularly impressive, given that Qt definitely doesn't have the same resources as Microsoft). I haven't used GTK+, but looking at the Hello World tutorial for it, it doesn't seem particularly intuitive. (e.g. why is the button label set with a callback?) Admittedly, there is some bias due to familiarity here, but I think my point is valid.
Github provides (private) hosting for proprietary projects, for a price. My guess is they didn't realise the gist wasn't protected similarly.
Easy way to find out: Mega could file a tortious inteference suit, and subpoena Paypal for the details. If it was one of the major processors, it'll be revealed and they can avail themselves of damages. If it was an NSL, that will become apparent too.
They are the best. Old laws were written way before all of the 'politics' which happens today.
There were politics back then too, it's just that the money was in different industries.
New laws are complex, and complexity is fraud. Some old laws are wrong, and have been thrown out, but if the longer the law has survived the better it is.
Two words: survivorship bias
I'm not sure if it's the same study, but the 25-hour rhythm is addressed in the article:
But Charles Czeisler, a professor of sleep medicine at Harvard and chief of the Division of Sleep Medicine at Harvard’s Brigham and Women’s Hospital, discovered that the 1970s finding of a 25-hour natural circadian rhythm for humans was wrong. The original study allowed test subjects to turn on artificial light whenever they wished, unintentionally resetting their bodies’ circadian rhythms.
At about the time Pathfinder landed, Czeisler and his team began conducting studies at the hospital’s special laboratory that shielded study subjects from all outside influences. With their test subjects in isolation, they simulated the Martian sol to see how the test subjects adjusted to the longer day. “What we learned was none of the people adapted their circadian rhythms to the Martian day,” Czeisler said.
Yes, dumb users are unable to exercise choices meaningfully, especially if they are unaware they even have a choice. But that doesn't mean that choice doesn't exist, and can't be exercised by even somewhat competent users. Googling "ubuntu change desktop environment" returns easily followed instructions for doing so via the GUI, so the only requirements are knowing how to use google, and what a desktop environment is (if they don't know the latter, they could easily find out by posting on the forum, or asking whichever person told them to try Ubuntu in the first place).
DE-specific releases don't exist because they're the only way of installing a DE, they exist because most people want to have a DE out of the box, but disagree which one to have.
Gnome 2 was released in 2002, and supported at least until the release of Gnome 3 in 2011 (9 years). In contrast, the WinXP was current for 6 years, and the Vista interface for 5 years until Win8. KDE has had a major release every 6 years, comparable to Windows. Xfce has been on version 4 for 12 years. Additionally, KDE4 is still supported, as is Gnome 2 (under the MATE project).
So by the numbers, the popular Linux DEs are at least as stable as Windows in terms of UI.
Now, if you want to argue that Linux is more fragmented in terms of UI because of this, that's a different discussion, but doing an apples to apples comparison shows that it is as stable/disruptive as Windows in the worst case (KDE), and significantly more stable in the other cases (Gnome and Xfce).
You can replace Gnome 3 with MATE or KDE without impairing your ability to run applications (you know, what you actually use the computer for). The same can't be said for replacing Windows.
I guess operating systems acquiring HiDPI support is one of the reasons going for the flat look. Vector graphics are easy to scale. But maybe some genius will eventually come up with a system that both scales well and looks cool.
KDE4 uses vector graphics for all of its icons, and none of them look 'flat' to me.Most of them have shadows, perspective, or some other kind of depth cue.