|
|
A couple of days ago, Bruce Schneier posted a blog entry that seems relevant. There's something in the military mindset about secrecy that I don't understand, and perhaps none of us do.
How people talked about the secrecy surrounding the Manhattan project.
That seems like an overreaction. You can't purchase anything from the Google Play Store without a Google account (which automatically means Plus). Why would they allow someone who can't use the Play Store to review an app there? That's nothing more than an open invitation for abuse.
Finally, cubieboard is 2x the cost. Newsflash: spend more, get more.
It's not 2x, it's less than 50% more expensive. +$14 on top of $35. For reliability, it's worth the extra cost. But it's not just reliability, it's also has useful interfaces that aren't present on the Pi, like SATA. SATA is worth the extra cost. But it's not jut reliability and SATA, it's also a whole lot faster and generally more capable. It's also a more open SoC.
Your perception that one socket for power is better than another is ridiculous, BTW
As another user suggested, it's not the form factor, is the available current. A USB wall wart is still going to be designed to conform to USB draw limitations. That means that a USB device attached to a Pi is capable of drawing as much power as the wart is designed to provide. That USB device + Pi are capable of drawing more.
It would make the system more reliable, yet. Not reliable, though. If you connect a USB device to the Pi that draws the maximum amount of power provided by the USB power input on the Pi, the two devices are still going to need more than is being input. Capacitors can take care of short bursts, but it's still possible to need more energy than is available, at which point the system will fail. Usually that'll mean a USB attached device will go offline, and some don't recover well. As we've seen, that's usually the Ethernet port, and you have to reset the Pi to fix the problem. It's gross.
Funny thing, I ordered a cubieboard this morning before this story was posted:
http://cubieboard.org/
Two of my roommates have RPis. One of them has two of them. I watched them both struggle with the RPi units when they were first setting them up. Those things are god awful. Graphics requires a binary blob, and the USB power source causes a lot of stability problems. Since the Ethernet is attached by USB, this normally manifests by the Ethernet dropping off, the kernel spewing messages about it, and the whole system reduced to a grinding mess as syslogd tries to write all that noise to the SD card. Running off of USB power is just ridiculous.
The cubieboard is 2x as fast, has 2-4x the memory, a SATA port, and Ethernet on the SoC rather than via USB. And, since it doesn't power off of a USB port I expect it to be a lot more stable. Most importantly to me: it doesn't require a binary blob for standard graphics.
They aren't being replaced. Each of these codenames is an additional optimization layer. The performance enhancements are cumulative.
Then someone decided "options are bad" and started taking it all away.
The guiding thought is that every option MULTIPLIES code complexity. Options tend to interact with other options, and testing is required to verify that all options work together, or that the system provides a means of preventing options that don't from being used together. The drive to simplify interfaces is intended to reduce the number of bugs present in the system.
As a secondary effect, removing optional behavior forces developers to make sure that the normal behavior is sane and doesn't need dozens of radio buttons on a configuration app.
GNOME Shell is universally hated.
No, it isn't. I have a number of non-tech friends (and my mom) who use Fedora with GNOME Shell. I use Fedora with GNOME Shell. I know a fairly large number of GNU/Linux users, and very few of them actually hate GNOME Shell. Not none, but few. For my part, I think notifications aren't very good, but otherwise the system does what it's supposed to. It stays out of my way. It isn't distracting and it uses minimal screen space. I like those things quite a lot.
Thus, they figure, it's better to remove every shred of choice. Because, you know, choice is hard and confusing.
People continue to repeat this reasoning, attributed to various developers, but that doesn't make it true. The guiding thought is not that users cannot make choices. It is that every option MULTIPLIES code complexity. Options tend to interact with other options, and testing is required to verify that all options work together, or that the system provides a means of preventing options that don't from being used together. The drive to simplify interfaces is intended to reduce the number of bugs present in the system.
As a secondary effect, removing optional behavior forces developers to make sure that the normal behavior is sane and doesn't need dozens of radio buttons on a configuration app.
being a memory hog
I understand people talking about Chrome being a faster browser, and I don't begrudge them that. However, anyone who contends that Chrome uses less memory doesn't know what they're talking about. Firefox uses less memory, is a smaller download, and is a much smaller installation than Chrome (particularly if you only measure code and leave out translations).
The Firefox installer on Win32 is almost half the size of Chrome, and the installed code is about half the size of Chrome as well. It's no wonder it uses less memory.
PLEASE STOP OFFERING THIS ADVICE.
Increasing your WAP broadcast power does nothing to improve signal in the other direction, so while it will make your mobile devices show more bars, it won't actually improve network performance. TCP doesn't work unless a host can both send and receive (packets need to be ACKed), so even if the client receives further away from the WAP, it'll stop getting new packets if it can't notify the sender that those packets were received.
All that really happens when you increase broadcast power is an increase in interference with neighboring WAPs, which tends to lead other people to the conclusion that they also need to increase broadcast power in order to overcome the interference that you created.
As far as I know, OS X uses very little GNU-produced or GPL-licensed code. XCode has replaced gcc with LLVM as the default compiler, and Samba has been replaced with an Apple-created SMB/CIFS server.
That's actually an interesting question. If NVIDIA wants to use the Linux API in the way that Google used the Java API for Dalvik, they would need to create a kernel that was capable of operating a computer system and supported all of the APIs that the NVIDIA binary driver used. If such a system existed, and was able to run X11 and the binary drivers, they may be able to argue that their driver was capable of operating independently of Linux and was not, therefore a derived work. NVIDIA might even be able to start with a FreeBSD or other permissively licensed system and add the Linux APIs that they wanted to use. They still wouldn't be licensed to use the implementation that appears in Linux, but it might be more difficult to successfully prosecute them for publishing source code that used a compatible interface.
I don't think a court would fail to see such a blatant attempt to evade the obligations of creating a derived work of the Linux kernel, but I have no basis on which to predict whether they'd find such an evasion to be illegal.
The shim can only call non-GPL-only APIs in the kernel.
Code on Linux, whether it runs in kernel space or not, calls Linux kernel functions. In order to differentiate what will and will not be considered a "derived work" of the GPL licensed kernel, some APIs are specifically designated as being non-public. These interfaces do not appear in non-Linux operating systems, and developers cannot claim that code which uses those interfaces will function independently of Linux. If the code cannot function independent of Linux, it is a derived work under the terms of the GPL.
Public interfaces, for comparison, do appear in non-Linux operating systems. Bash can operate on FreeBSD because FreeBSD supports the APIs used by Bash. Bash, therefore, can function independently of Linux and is not a derived work.
No, this is the sort of thing I'm talking about:
http://thinkprogress.org/election/2012/10/07/972501/gop-strategist-admits-romney-is-witholding-details-of-his-tax-plan-to-avoid-criticism/
That line of reasoning has been the campaign's excuse for not being specific about their tax plans.
Deprive a mirror of its silver and even the Czar won't see his face.