As the post you replied to indicated, Ubuntu 12.04 is supported until 2017. If this accessibility issue is as serious as it sounds, certainly it will get fixed within the next 3 years?
X is not Windows. While I do sometimes get the annoying popup on Windows systems, I have never had that issue on my KDE desktop. Even on Windows there's a configuration option in the Control Panel to disable it. So no, it is not a "burden" to anyone, really. Unless you're using Windows (which isn't what this topic was about anyway), and are too lazy to spend 30 seconds on Google figuring out how to disable it.
I'll grant you that maybe Windows should have the feature disabled by default...
If I'm reading the description of the issue correctly, the problem is that an option that used to modify the behavior of the Sticky Keys feature now does nothing. How is that not a bug, by any stretch of the imagination?
Beer is, by definition, based on fermented grain. Sure, there are other (at times odd) ingredients involved in these ancient recipes, but at the end of the day Dogfish Head is a commercial craft brewery, and a very successful one at that. They didn't get where they are by making beers that suck. I've had quite a few of their beers, and while some definitely qualify as strange, most of them are quite good, and all of them are at least interesting.
Modern "embedded" x86 processors generally sacrifice a fair amount of performance to meet their target power/heat numbers. Once you make those concessions, the performance gap relative to ARM narrows considerably. Furthermore, the most computationally demanding tasks in the embedded space tend to be either graphics/video (which will use embedded GPU hardware) or amenable to running on a DSP (implemented using GPU compute or dedicated DSP hardware).
ABI = Application Binary Interface. Defines the pointer sizes and conventions for passing function arguments at the object code level (among other things). The ABI determines how the compiler generates object code for function call/entry/exit, and the width of pointer types.
API defines the interfaces seen by the programmer.
This sure feels a lot like a throwback to the old 16-bit DOS days, where you had small/medium/large memory models depending on the size of your code and data address spaces. We've already got 32-bit mode for supporting pure 32-bit apps and 64-bit mode for pure 64-bit; supporting yet a third ABI is just going to result in more bloat as all the runtime libraries need to be duplicated for yet another combination of code/data pointer size.
I hate to say this since I'm sure a lot of smart people put significant effort into this, but it seems like a solution in search of a problem. RAM is cheap, and the performance advantage of using 32-bit pointers is typically small.
For most embedded applications you're probably better off just running a 32-bit OS and calling it a day. Embedded is mostly on 32-bit ARM processors anyway.
They don't deny that they entered into a deal. They deny that they entered into a deal "with the intention of weakening RSA’s products, or introducing potential ‘backdoors’ into our products". In other words, there was a deal, but they are insisting that they didn't realize at the time that the algorithm had a backdoor.
If there was no deal at all, they wouldn't have felt a need to qualify the denial with the above quoted text.
Ubuntu isn't even really an exception. You can still install the barebones "server" flavor, then drop whatever DE you want on top of that. Or start with one DE, then install another DE alongside it. As far as I'm concerned it is just a nit-picky detail of what they happen to promote as the default distribution image.
The article quotes the CEO as saying the company is struggling due to "capital constraints". Then right below that, "This has been a common refrain. OCZ reports lower sales, it blames a shortage of NAND." Does the author truly not understand the difference between a shortage of cash to fund ongoing operations, and a shortage of parts?
Regardless, I don't see their departure from the scene as a great loss. Their spotty reputation for quality and customer service has caused me to avoid their products in general, and has apparently come back to bite them in the ass. The only sad part is that they might take PC Power and Cooling (one of the premier PSU manufacturers from back in the day, which OCZ acquired a few years ago) down with the ship.
Agree 100% with your disdain for "technology as panacea". However, if these tablets did not meet the specs stipulated in the contract that's still fraud regardless of whether it was a good idea in the first place.
Bingo. Comparing the breakage rate for tablets that have been handed out to middle schoolers to that for tablets which have been bought by (and presumably used mostly by) adults is meaningless.
That said, if the contract stipulated that they were supposed to have Gorilla Glass screens and they didn't come so equipped, then that's fraud. If fraud is proven, then hopefully this results in some hefty financial penalties and/or jail time for those responsible.
The problem with being solely dependent on binary drivers is that hardware vendors eventually stop supporting older hardware on newer OSes. With a viable Open Source driver, it is (almost) guaranteed that you will still be able to use your device in the next version of Windows, Linux, etc., even if the hardware vendor declines to port the driver or goes out of business.
I don't see what's so hard to sort out. They make a decision to publish the register-level hardware specs, and they post them. All the Open Source devs need is access to the same hardware documentation that nVidia's own driver developers use; they're not looking for the source code to the existing proprietary drivers (though nVidia releasing their own drivers under an Open Source license would be great too).
The main reason Open Source video drivers for newer nVidia and AMD GPUs have had such a checkered history is precisely the lack of public hardware specs. The driver teams have been forced to reverse-engineer some of the hardware features to develop the drivers, which is far from ideal.
Open Source drivers for Intel GPUs have historically been pretty good (well, at least until they started using the PowerVR-based junk...); the issue there has been slow hardware, not buggy drivers.
We're hitting a wall on single threaded performance due to clock speed limitations, but CPU cores keep getting smaller and more power efficient. In a few years, we'll have the ability to put 32 or more cores in consumer CPUs, and it wouldn't surprise me if we have 8 core CPUs in smartphones and tablets. The key to continued performance improvements is better multi-threaded code, to allow us to effectively split up the workload across more cores.
The capacity of MicroSD cards has improved a bit since then, resulting in a moderate increase in achievable bandwidth; but other than that the analysis is still essentially the same.
Until a few months ago at work I was running triple-head on an Ubuntu 10.04 LTS desktop with an ATI Radeon something-or-other card. Hardware acceleration was supported. The third head was analog, but AFAIK that was just a limitation of the sub-$150 graphics card I was using (only 2 digital ports), not something inherent in X or the drivers. I was surprised to discover that triple head was even possible with an inexpensive card.
I did need to install a beta version of the proprietary drivers, and IIRC it took a bit of finagling with xrandr in a startup script to get the heads to consistently come up in the correct order (stupid Catalyst Control Center!), but once I got those issues sorted it worked reasonably well.
Something like an email or text to a laptop at home, or a dedicated prepaid phone, but without the pitfalls of such a solution (i.e. random wrong numbers, solicitors, email spam, etc).
Just set up a new e-mail account for the alerts to go to, and don't publish the address or use the account to send any outgoing e-mails. In order for you to receive spam at an address, first that address needs to be out there to be harvested.
Maybe whoever was building their boards for them got some counterfeit caps. In my experience, the worst brands for capacitor problems were MSI, Abit, and FIC. ECS was notorious as well, but I never owned one personally. But apparently nobody was immune; I've had a couple of Asus boards that developed cap issues, as well as other random gear from that era (Netgear Ethernet switches/routers, etc.)
Whether it's your brand of switch, motherboard or even memory, never have the same across all machines if you can help it. The only time I'd recommend the same brand would be hard drives (due to concurrency issues), but then at least try go get them from different batches.
...and then along comes something like the Seagate 7200.11 firmware bug from a few years back, which caused all drives of several related models to self-brick after a period of time.
Slashdot Mirror
As the post you replied to indicated, Ubuntu 12.04 is supported until 2017. If this accessibility issue is as serious as it sounds, certainly it will get fixed within the next 3 years?
X is not Windows. While I do sometimes get the annoying popup on Windows systems, I have never had that issue on my KDE desktop. Even on Windows there's a configuration option in the Control Panel to disable it. So no, it is not a "burden" to anyone, really. Unless you're using Windows (which isn't what this topic was about anyway), and are too lazy to spend 30 seconds on Google figuring out how to disable it.
I'll grant you that maybe Windows should have the feature disabled by default...
If I'm reading the description of the issue correctly, the problem is that an option that used to modify the behavior of the Sticky Keys feature now does nothing. How is that not a bug, by any stretch of the imagination?
Beer is, by definition, based on fermented grain. Sure, there are other (at times odd) ingredients involved in these ancient recipes, but at the end of the day Dogfish Head is a commercial craft brewery, and a very successful one at that. They didn't get where they are by making beers that suck. I've had quite a few of their beers, and while some definitely qualify as strange, most of them are quite good, and all of them are at least interesting.
Modern "embedded" x86 processors generally sacrifice a fair amount of performance to meet their target power/heat numbers. Once you make those concessions, the performance gap relative to ARM narrows considerably. Furthermore, the most computationally demanding tasks in the embedded space tend to be either graphics/video (which will use embedded GPU hardware) or amenable to running on a DSP (implemented using GPU compute or dedicated DSP hardware).
ABI = Application Binary Interface. Defines the pointer sizes and conventions for passing function arguments at the object code level (among other things). The ABI determines how the compiler generates object code for function call/entry/exit, and the width of pointer types.
API defines the interfaces seen by the programmer.
This sure feels a lot like a throwback to the old 16-bit DOS days, where you had small/medium/large memory models depending on the size of your code and data address spaces. We've already got 32-bit mode for supporting pure 32-bit apps and 64-bit mode for pure 64-bit; supporting yet a third ABI is just going to result in more bloat as all the runtime libraries need to be duplicated for yet another combination of code/data pointer size.
I hate to say this since I'm sure a lot of smart people put significant effort into this, but it seems like a solution in search of a problem. RAM is cheap, and the performance advantage of using 32-bit pointers is typically small.
For most embedded applications you're probably better off just running a 32-bit OS and calling it a day. Embedded is mostly on 32-bit ARM processors anyway.
Please read the complete RSA press release and parse it carefully: https://blogs.rsa.com/news-media-2/rsa-response/
They don't deny that they entered into a deal. They deny that they entered into a deal "with the intention of weakening RSA’s products, or introducing potential ‘backdoors’ into our products". In other words, there was a deal, but they are insisting that they didn't realize at the time that the algorithm had a backdoor.
If there was no deal at all, they wouldn't have felt a need to qualify the denial with the above quoted text.
Ubuntu isn't even really an exception. You can still install the barebones "server" flavor, then drop whatever DE you want on top of that. Or start with one DE, then install another DE alongside it. As far as I'm concerned it is just a nit-picky detail of what they happen to promote as the default distribution image.
I was under the impression that they were actually PCP&C designs manufactured by Seasonic under contract. But I could be mistaken.
The article quotes the CEO as saying the company is struggling due to "capital constraints". Then right below that, "This has been a common refrain. OCZ reports lower sales, it blames a shortage of NAND." Does the author truly not understand the difference between a shortage of cash to fund ongoing operations, and a shortage of parts?
Regardless, I don't see their departure from the scene as a great loss. Their spotty reputation for quality and customer service has caused me to avoid their products in general, and has apparently come back to bite them in the ass. The only sad part is that they might take PC Power and Cooling (one of the premier PSU manufacturers from back in the day, which OCZ acquired a few years ago) down with the ship.
Agree 100% with your disdain for "technology as panacea". However, if these tablets did not meet the specs stipulated in the contract that's still fraud regardless of whether it was a good idea in the first place.
Bingo. Comparing the breakage rate for tablets that have been handed out to middle schoolers to that for tablets which have been bought by (and presumably used mostly by) adults is meaningless.
That said, if the contract stipulated that they were supposed to have Gorilla Glass screens and they didn't come so equipped, then that's fraud. If fraud is proven, then hopefully this results in some hefty financial penalties and/or jail time for those responsible.
Maybe that was meant to be in dog years. Or something.
The problem with being solely dependent on binary drivers is that hardware vendors eventually stop supporting older hardware on newer OSes. With a viable Open Source driver, it is (almost) guaranteed that you will still be able to use your device in the next version of Windows, Linux, etc., even if the hardware vendor declines to port the driver or goes out of business.
I don't see what's so hard to sort out. They make a decision to publish the register-level hardware specs, and they post them. All the Open Source devs need is access to the same hardware documentation that nVidia's own driver developers use; they're not looking for the source code to the existing proprietary drivers (though nVidia releasing their own drivers under an Open Source license would be great too).
The main reason Open Source video drivers for newer nVidia and AMD GPUs have had such a checkered history is precisely the lack of public hardware specs. The driver teams have been forced to reverse-engineer some of the hardware features to develop the drivers, which is far from ideal.
Open Source drivers for Intel GPUs have historically been pretty good (well, at least until they started using the PowerVR-based junk...); the issue there has been slow hardware, not buggy drivers.
We're hitting a wall on single threaded performance due to clock speed limitations, but CPU cores keep getting smaller and more power efficient. In a few years, we'll have the ability to put 32 or more cores in consumer CPUs, and it wouldn't surprise me if we have 8 core CPUs in smartphones and tablets. The key to continued performance improvements is better multi-threaded code, to allow us to effectively split up the workload across more cores.
http://www.dansdata.com/gz105.htm
The capacity of MicroSD cards has improved a bit since then, resulting in a moderate increase in achievable bandwidth; but other than that the analysis is still essentially the same.
Until a few months ago at work I was running triple-head on an Ubuntu 10.04 LTS desktop with an ATI Radeon something-or-other card. Hardware acceleration was supported. The third head was analog, but AFAIK that was just a limitation of the sub-$150 graphics card I was using (only 2 digital ports), not something inherent in X or the drivers. I was surprised to discover that triple head was even possible with an inexpensive card.
I did need to install a beta version of the proprietary drivers, and IIRC it took a bit of finagling with xrandr in a startup script to get the heads to consistently come up in the correct order (stupid Catalyst Control Center!), but once I got those issues sorted it worked reasonably well.
Something like an email or text to a laptop at home, or a dedicated prepaid phone, but without the pitfalls of such a solution (i.e. random wrong numbers, solicitors, email spam, etc).
Just set up a new e-mail account for the alerts to go to, and don't publish the address or use the account to send any outgoing e-mails. In order for you to receive spam at an address, first that address needs to be out there to be harvested.
Maybe we should import Mexican candy and ferment it into ethanol!
Maybe whoever was building their boards for them got some counterfeit caps. In my experience, the worst brands for capacitor problems were MSI, Abit, and FIC. ECS was notorious as well, but I never owned one personally. But apparently nobody was immune; I've had a couple of Asus boards that developed cap issues, as well as other random gear from that era (Netgear Ethernet switches/routers, etc.)
Whether it's your brand of switch, motherboard or even memory, never have the same across all machines if you can help it. The only time I'd recommend the same brand would be hard drives (due to concurrency issues), but then at least try go get them from different batches.
...and then along comes something like the Seagate 7200.11 firmware bug from a few years back, which caused all drives of several related models to self-brick after a period of time.