The Thubans were good, but everything based on Bulldozer just blows through power while having terrible IPC, thanks to having shared integer and floating point units. If they were to be honest the "modules" would be treated as single cores with hardware assisted hyperthreading, because the benches show that is a hell of a lot closer to what they are than to true cores.
Errrm, all of the integer units are dedicated and the shared floating point units still give each core as much floating-point resources as on the previous generation of AMD chips even if every single core is using floating point 100% of the time. If AMD hadn't screwed up on the engineering side, it'd be a really great design.
The more additional 'features' you add, the more likely the average user* will screw them up and open a hole.
Not just the average user either; it's easy for the average developer to screw up and leave a hole too. For instance, under Windows many application installers need to install one or more system-wide services (it's basically mandatory if you want to do automatic updates). As part of the service installation process, you need to specify the ACL to be applied to the newly-created service. Lots of app developers such as Adobe screwed this up and set a generic wide-open ACL, which meant any user on the system could get root by editing the service configuration and pointing it at a malicious executable they'd created.
I seem to recall this and other interesting holes weren't spotted until someone designed an automated checker and gave it a full model of how Windows security worked because it's just that complicated.
That's basically Wayland in a nutshell though - it's simple because they've left all the hard parts, such as network transparency, for someone else to deal with. Then because they've designed the thing on the assumption that they don't have to worry about network transparency it's wound up with a whole bunch of design choices that make it hard to forward over the network.
Actually, I'm not sure it does - how do you scale mouse input if you're just scaling the window to fill the display rather than changing the display resolution, for instance?
Historically, you couldn't get 3D acceleration on any desktop except the first. I'm not sure if that's true anymore, though it probably is for some of the proprietary drivers at least.
They've been arseholes. I'm pretty sure the reason the court ruled that they had to make an apology was because they've been arseholes. In fact, Apple are such arseholes that when the court first ruled against them in this case, before the court further forced them to apologize to Samsung, they released a statement to the press which basically made it sound like the court had ruled in their favour
I have to disagree. ZFS was infamous for filesystem metadata corruption issues amongst people who tried to use it seriously. If you were lucky it detected the corruption and remounted read-only, otherwise it kernel paniced the moment you tried to mount the FS and there was no way to recover data short of manually repairing the FS with a hex editor (ZFS didn't have a working fsck, partly for marketing reasons).
Actually, we do know of one really lovely bug in Windows Home Server. It didn't corrupt the filesystem metadata, but if you were foolish enough to save files to it from applications like Word the actual data got corrupted. Microsoft's advice was not to save data in ways that lead to it becoming corrupted; they didn't fix the underlying issue for months.
Mod parent up. This is actually par for the course with toolchains and libraries in Microsoft-land; they did the same with GDI+, and the same with COM and MFC before that. If you're a Microsoft developer you have to run as fast as you can just to keep up.
That doesn't surprise me. I suspect that some of the delay may have been due to Broadcom developing both sides of the driver as a single code base; the buffer management also looks like it might rely on them having similar code on both sides.
That's my hope. My issue with the purists is that it's not obviously clear why they want to see the microcode running on a proprietary RISC core inside the GPU, but not for example the Verilog.
Most likely because no-one's going to convert (for instance) their entire OpenGL ES driver implementation to Verilog and shove it down into hardware in order to claim to be open source, whilst adding a proprietary RISC core to the GPU and moving the driver on to that is a lot more practical but still destroys most of the reasons why people would want open source drivers in the first place. For instance, if the shader compiler chokes on your code and you want to figure out why, you're stuffed. If the shader compiler can't compile your code efficiently you're stuffed. If what you're doing maps well onto the underlying graphics hardware but poorly onto the more limited OpenGL ES API - which is I believe one of the reasons getting accelerated X rendering is so hard on the Pi - you're stuffed. (Also, if you force it down into Verilog you're in essentially the same boat as your users if it doesn't work.)
By the way, what you're doing is a fairly transparent abuse of Stallman's public statements in my opinion. His viewpoint is AIUI that if it's code even the manufacturer didn't feel the need to be able to modify in the field, he probably wouldn't need to either. You're basically taking that and saying that, even though you'd like to be able to modify the code in question, you're going to offer a model where you lock it down so that you can claim to be open source without letting anyone else look at and modify the source either. That is really not something that Stallman would agree to.
The "much higher-level interface" is basically just the OpenGL ES API, though. For instance, this file contains Broadcom's ARM-side code for the vast majority of the OpenGL ES API calls, and it literally just forwards them over RPC to the closed firmware running on the VideoCore GPU. Even shader compilation runs entirely on the closed VideoCore. As far as I can tell, the only thing that doesn't is context setup and buffer management, which appears to involve mucking with some undocumented and decidedly low-level datastructures shared with the VideoCore.
In terms of helping people to understand how it works - or more importantly why it isn't working for them - this provides about as much information as a proprietary blob. Either way you're blindly calling into someone else's closed implementation of OpenGL ES.
Apparently - and I haven't confirmed this personally myself yet - the ARM code for the GPU is basically a thin RPC layer that forwards OpenGL API calls to the actual GPU driver, running on the GPU, which does all the interesting stuff. It's kind of a practical demonstration of why Richard Stallman is so opposed to binary blobs even if they don't run on the main CPU - if you find a bug in the drivers, you still can't fix it because it's almost certain to be in the bit for which you don't even have a disassembler or instruction set documentation, let alone source code. The real question is, what did Broadcom think was so important about their shim layer that they needed to keep it closed source in the first place?
I'm not sure if it's an issue with their livestream or VLC, but the stream seems to be incompatible with VLC. It plays for a minute or so and then falls over with an error about sequence numbers as soon as it reaches the next segment of the stream.
Possibly even before Windows 95. For instance the next time you need to close a window try double-clicking the icon in the top left. That feature was included in Windows solely to smooth the transition for Windows 3.1 users who were used to doing it that way, along with of fully-working versions of the Windows 3.1-style Program Manager and File Manager.
If the management API and web interface go down throughout the entireity of AWS, as they did in this outage according to some users, good luck bringing up another server. Besides, everyone else had the same idea - if one region goes down, we can just bring up a server in another region, so we don't have to pay for servers in multiple data centers - so it turned out there weren't actually nearly enough servers available for them to do this.
Normal USB doesn't require excessive interrupt-time processing. The USB controller on the Raspberry Pi, on the other hand, implements most of the USB controller functionality in software and was taking up something like 15% of the CPU time just in USB-related interrupt handling before they optimized the driver - even if you weren't actively using USB! Also, it turns out that the Pi has trouble meeting the real-time requirements of its USB controller too because the SD card driver causes excessive interrupt latency. This was one of the reasons why people had so many problems with USB devices on the Pi.
The Pi can't accomplish the same tasks though. In fact, I don't think you can even run code that has relatively relaxed soft real time requirements on it (such as, say, controlling a 3D printer or CNC mill) because its SD card and USB drivers do horrible things to interrupt latency. A desktop PC might actually be more capable of accomplishing some traditional microcontroller tasks than the Pi.
"This century's most fatal security disaster"? Sounds pretty flamebaity to me. (This is also not the worst certificate-related screw-up even within the last year, either - for instance Microsoft has done worse by accidentally giving out certificates that allow attackers to sign fake Windows updates and not fixing the problem until it was exploited in the wild to compromise a number of Windows systems.)
Same thing when novel but inferior algorithms are presented. For example, I once saw polynomial prediction applied to a specific problem where linear prediction had already been well studied - the results were worse in every possible way, but the novelty factor was enough to push it through.
Surely that's a useful thing to publish though - it tells everyone else in the field that approach has been tried already and doesn't work very well.
ICANN charged a fairly substantial non-refundable entrance fee for each application and allowed multiple companies to apply for the same gTLD, but obviously only one company can get each one. They're now planning on picking which applicant actually receives something for the money they've paid at random. That's pretty clearly a raffle.
Free markets cannot exist, full stop. For instance, every time a companies actions have negative externalities - costs that affect others who aren't doing business with them - that distorts the market even if there's no government, because it means the free market price of their product doesn't reflect the actual cost. We see this with global warming; in fact that's one reason why libertarians are so keen on insisting that it doesn't exist despite the actual evidence. There's a related problem with (for instance) deep sea fishing called the tragedy of the commons - without government intervention the free market would wipe out fish stocks and drive fishermen into bankrupcy, despite the fact that this makes everyone else worse off.
That's before we even get into the problems with false advertising and food and drug mislabelling, and the consistent inability of the free market to deal with it, or natural monopolies and rent-seeking behaviour, or...
May work, may just result in the low-income going unwashed because they can't afford more than drinking water.
You assume that they'll even be able to afford drinking water. That's probably a bad assumption. We've already had outbreaks of dysentry amongst the poor here in the UK from Thatcher privatising the water industry; they only stopped once the government banned water companies from cutting off people's water altogether.
Slashdot Mirror
The Thubans were good, but everything based on Bulldozer just blows through power while having terrible IPC, thanks to having shared integer and floating point units. If they were to be honest the "modules" would be treated as single cores with hardware assisted hyperthreading, because the benches show that is a hell of a lot closer to what they are than to true cores.
Errrm, all of the integer units are dedicated and the shared floating point units still give each core as much floating-point resources as on the previous generation of AMD chips even if every single core is using floating point 100% of the time. If AMD hadn't screwed up on the engineering side, it'd be a really great design.
The more additional 'features' you add, the more likely the average user* will screw them up and open a hole.
Not just the average user either; it's easy for the average developer to screw up and leave a hole too. For instance, under Windows many application installers need to install one or more system-wide services (it's basically mandatory if you want to do automatic updates). As part of the service installation process, you need to specify the ACL to be applied to the newly-created service. Lots of app developers such as Adobe screwed this up and set a generic wide-open ACL, which meant any user on the system could get root by editing the service configuration and pointing it at a malicious executable they'd created.
I seem to recall this and other interesting holes weren't spotted until someone designed an automated checker and gave it a full model of how Windows security worked because it's just that complicated.
That's basically Wayland in a nutshell though - it's simple because they've left all the hard parts, such as network transparency, for someone else to deal with. Then because they've designed the thing on the assumption that they don't have to worry about network transparency it's wound up with a whole bunch of design choices that make it hard to forward over the network.
Actually, I'm not sure it does - how do you scale mouse input if you're just scaling the window to fill the display rather than changing the display resolution, for instance?
Historically, you couldn't get 3D acceleration on any desktop except the first. I'm not sure if that's true anymore, though it probably is for some of the proprietary drivers at least.
They've been arseholes. I'm pretty sure the reason the court ruled that they had to make an apology was because they've been arseholes. In fact, Apple are such arseholes that when the court first ruled against them in this case, before the court further forced them to apologize to Samsung, they released a statement to the press which basically made it sound like the court had ruled in their favour
I have to disagree. ZFS was infamous for filesystem metadata corruption issues amongst people who tried to use it seriously. If you were lucky it detected the corruption and remounted read-only, otherwise it kernel paniced the moment you tried to mount the FS and there was no way to recover data short of manually repairing the FS with a hex editor (ZFS didn't have a working fsck, partly for marketing reasons).
Actually, we do know of one really lovely bug in Windows Home Server. It didn't corrupt the filesystem metadata, but if you were foolish enough to save files to it from applications like Word the actual data got corrupted. Microsoft's advice was not to save data in ways that lead to it becoming corrupted; they didn't fix the underlying issue for months.
Mod parent up. This is actually par for the course with toolchains and libraries in Microsoft-land; they did the same with GDI+, and the same with COM and MFC before that. If you're a Microsoft developer you have to run as fast as you can just to keep up.
WinCE is a real-time OS made for sat-navs and embedded devices, and also forms the core of WinPhone7.
But not the core of WinPhone8, which is IIRC going to run the full Windows kernel instead.
That doesn't surprise me. I suspect that some of the delay may have been due to Broadcom developing both sides of the driver as a single code base; the buffer management also looks like it might rely on them having similar code on both sides.
That's my hope. My issue with the purists is that it's not obviously clear why they want to see the microcode running on a proprietary RISC core inside the GPU, but not for example the Verilog.
Most likely because no-one's going to convert (for instance) their entire OpenGL ES driver implementation to Verilog and shove it down into hardware in order to claim to be open source, whilst adding a proprietary RISC core to the GPU and moving the driver on to that is a lot more practical but still destroys most of the reasons why people would want open source drivers in the first place. For instance, if the shader compiler chokes on your code and you want to figure out why, you're stuffed. If the shader compiler can't compile your code efficiently you're stuffed. If what you're doing maps well onto the underlying graphics hardware but poorly onto the more limited OpenGL ES API - which is I believe one of the reasons getting accelerated X rendering is so hard on the Pi - you're stuffed. (Also, if you force it down into Verilog you're in essentially the same boat as your users if it doesn't work.)
By the way, what you're doing is a fairly transparent abuse of Stallman's public statements in my opinion. His viewpoint is AIUI that if it's code even the manufacturer didn't feel the need to be able to modify in the field, he probably wouldn't need to either. You're basically taking that and saying that, even though you'd like to be able to modify the code in question, you're going to offer a model where you lock it down so that you can claim to be open source without letting anyone else look at and modify the source either. That is really not something that Stallman would agree to.
The "much higher-level interface" is basically just the OpenGL ES API, though. For instance, this file contains Broadcom's ARM-side code for the vast majority of the OpenGL ES API calls, and it literally just forwards them over RPC to the closed firmware running on the VideoCore GPU. Even shader compilation runs entirely on the closed VideoCore. As far as I can tell, the only thing that doesn't is context setup and buffer management, which appears to involve mucking with some undocumented and decidedly low-level datastructures shared with the VideoCore.
In terms of helping people to understand how it works - or more importantly why it isn't working for them - this provides about as much information as a proprietary blob. Either way you're blindly calling into someone else's closed implementation of OpenGL ES.
Apparently - and I haven't confirmed this personally myself yet - the ARM code for the GPU is basically a thin RPC layer that forwards OpenGL API calls to the actual GPU driver, running on the GPU, which does all the interesting stuff. It's kind of a practical demonstration of why Richard Stallman is so opposed to binary blobs even if they don't run on the main CPU - if you find a bug in the drivers, you still can't fix it because it's almost certain to be in the bit for which you don't even have a disassembler or instruction set documentation, let alone source code. The real question is, what did Broadcom think was so important about their shim layer that they needed to keep it closed source in the first place?
I'm not sure if it's an issue with their livestream or VLC, but the stream seems to be incompatible with VLC. It plays for a minute or so and then falls over with an error about sequence numbers as soon as it reaches the next segment of the stream.
Possibly even before Windows 95. For instance the next time you need to close a window try double-clicking the icon in the top left. That feature was included in Windows solely to smooth the transition for Windows 3.1 users who were used to doing it that way, along with of fully-working versions of the Windows 3.1-style Program Manager and File Manager.
If the management API and web interface go down throughout the entireity of AWS, as they did in this outage according to some users, good luck bringing up another server. Besides, everyone else had the same idea - if one region goes down, we can just bring up a server in another region, so we don't have to pay for servers in multiple data centers - so it turned out there weren't actually nearly enough servers available for them to do this.
Normal USB doesn't require excessive interrupt-time processing. The USB controller on the Raspberry Pi, on the other hand, implements most of the USB controller functionality in software and was taking up something like 15% of the CPU time just in USB-related interrupt handling before they optimized the driver - even if you weren't actively using USB! Also, it turns out that the Pi has trouble meeting the real-time requirements of its USB controller too because the SD card driver causes excessive interrupt latency. This was one of the reasons why people had so many problems with USB devices on the Pi.
The Pi can't accomplish the same tasks though. In fact, I don't think you can even run code that has relatively relaxed soft real time requirements on it (such as, say, controlling a 3D printer or CNC mill) because its SD card and USB drivers do horrible things to interrupt latency. A desktop PC might actually be more capable of accomplishing some traditional microcontroller tasks than the Pi.
"This century's most fatal security disaster"? Sounds pretty flamebaity to me. (This is also not the worst certificate-related screw-up even within the last year, either - for instance Microsoft has done worse by accidentally giving out certificates that allow attackers to sign fake Windows updates and not fixing the problem until it was exploited in the wild to compromise a number of Windows systems.)
Same thing when novel but inferior algorithms are presented. For example, I once saw polynomial prediction applied to a specific problem where linear prediction had already been well studied - the results were worse in every possible way, but the novelty factor was enough to push it through.
Surely that's a useful thing to publish though - it tells everyone else in the field that approach has been tried already and doesn't work very well.
ICANN charged a fairly substantial non-refundable entrance fee for each application and allowed multiple companies to apply for the same gTLD, but obviously only one company can get each one. They're now planning on picking which applicant actually receives something for the money they've paid at random. That's pretty clearly a raffle.
Free markets cannot exist, full stop. For instance, every time a companies actions have negative externalities - costs that affect others who aren't doing business with them - that distorts the market even if there's no government, because it means the free market price of their product doesn't reflect the actual cost. We see this with global warming; in fact that's one reason why libertarians are so keen on insisting that it doesn't exist despite the actual evidence. There's a related problem with (for instance) deep sea fishing called the tragedy of the commons - without government intervention the free market would wipe out fish stocks and drive fishermen into bankrupcy, despite the fact that this makes everyone else worse off.
That's before we even get into the problems with false advertising and food and drug mislabelling, and the consistent inability of the free market to deal with it, or natural monopolies and rent-seeking behaviour, or...
That was basically the business model of Gaikai, the more successful competitor bought out by Sony for $380 million
May work, may just result in the low-income going unwashed because they can't afford more than drinking water.
You assume that they'll even be able to afford drinking water. That's probably a bad assumption. We've already had outbreaks of dysentry amongst the poor here in the UK from Thatcher privatising the water industry; they only stopped once the government banned water companies from cutting off people's water altogether.