Shuttleworth Wants To Get Rid of Proprietary Firmware

← Back to Stories (view on slashdot.org)

Shuttleworth Wants To Get Rid of Proprietary Firmware

Posted by samzenpus on Monday March 17, 2014 @06:39AM from the change-your-ways dept.

jones_supa writes "In a new blog post, the Ubuntu main man Mark Shuttleworth calls for an end to proprietary firmwares such as ACPI. His reasoning is that running any firmware code on your phone, tablet, PC, TV, wifi router, washing machine, server, or the server running the cloud your SAAS app is running on, is a threat vector against you, and NSA's best friend. 'Arguing for ACPI on your next-generation device is arguing for a trojan horse of monumental proportions to be installed in your living room and in your data center. I've been to Troy, there is not much left.' As better solutions, Shuttleworth suggests delivering your innovative code directly to the upstream kernel, or using declarative firmware that describes hardware linkages and dependencies but doesn't include executable code."

147 comments

Min score:

Reason:

Sort:

Precisely how... by msobkow · 2014-03-17 06:43 · Score: 1

Precisely how does he intend that a machine boot to the install media without executable firmware?
Or is he a proponent of the "disposable machine" -- once infected, you *have* to replace it, because you can't *reinstall*?

--
I do not fail; I succeed at finding out what does not work.
1. Re:Precisely how... by jones_supa · 2014-03-17 06:45 · Score: 3, Insightful
  
  Getting rid of ACPI sounds also like a "good luck with that" plan.
2. Re:Precisely how... by TechyImmigrant · 2014-03-17 06:56 · Score: 5, Insightful
  
  I design hardware. I could wait for someone to accept my changes into the Linux Kernel before I start testing it, or I could write some firmware accessible through ACPI.
  What Shutters wants is irrelevant. What he needs is open interface specifications to the hardware.
  
  --
  I should use this sig to advertise my book ISBN-13 : 978-1501515132.
3. Re:Precisely how... by Anonymous Coward · 2014-03-17 06:58 · Score: 5, Informative
  
  Firmware is just fine, as long as it's non-proprietary--free as in freedom.
4. Re:Precisely how... by jones_supa · 2014-03-17 06:58 · Score: 2
  
  ACPI WMI specs from the HW makers would be nice. It's frustrating how many laptops have broken hotkeys under Linux.
5. Re:Precisely how... by SuricouRaven · 2014-03-17 07:00 · Score: 1
  
  DIL socket. Add your own firmware chip.
6. Re:Precisely how... by fuzzyfuzzyfungus · 2014-03-17 07:01 · Score: 1
  
  Getting rid of ACPI sounds also like a "good luck with that" plan.
  If anything, insufferably shitty firmware has been steadily bloating to the point where we should probably start including it in operating system marketshare charts...
7. Re:Precisely how... by amorsen · 2014-03-17 07:04 · Score: 4, Informative
  
  Precisely how does he intend that a machine boot to the install media without executable firmware?
  He does not complain about executable, he complains about proprietary.
  Besides, ACPI is complete overkill for booting.
  
  --
  Finally! A year of moderation! Ready for 2019?
8. Re:Precisely how... by Anonymous Coward · 2014-03-17 07:05 · Score: 0
  
  As far as I know, ACPI is not involved in booting.
9. Re:Precisely how... by fuzzyfuzzyfungus · 2014-03-17 07:07 · Score: 2
  
  ACPI WMI specs from the HW makers would be nice. It's frustrating how many laptops have broken hotkeys under Linux.
  If we are currently at the point where you can't even get the details of what the Windows Management Instrumentation blobs embedded in the motherboard firmware mean, that might be another reason why somebody running a Linux company might dislike ACPI...
  
  As long as (through some mixture of overt standard-setting to that effect, and basic 'you actually think that we are going to keep testing our BIOS once it boots Windows? That means that it's ready to ship!' OEM engineering) proprietary firmware is basically the lowest level of Windows drivers, writing other OSes on top of it just isn't going to be a pleasant experience.
10. Re:Precisely how... by PopeRatzo · 2014-03-17 07:16 · Score: 2
  
  What he needs is open interface specifications to the hardware.
  That. Absolutely.
  Shuttleworth may be slightly off the mark, but his dislike for proprietary firmware is worth supporting, given what we're learning daily about what people who mean us no good are doing with our consumer electronics.
  
  --
  You are welcome on my lawn.
11. Re:Precisely how... by msobkow · 2014-03-17 07:20 · Score: 1
  
  So you can't power off the machine while it's booting?
  Give your head a shake.
  
  --
  I do not fail; I succeed at finding out what does not work.
12. Re:Precisely how... by Lumpy · 2014-03-17 07:21 · Score: 1
  
  and he will NEVER get it.
  Hell you cant get open microcode on the freaking processors.
  Shuttleworth is starting to become a little nutty.
  
  --
  Do not look at laser with remaining good eye.
13. Re:Precisely how... by msobkow · 2014-03-17 07:22 · Score: 1
  
  Then again, I have to hold down the power switch until it takes effect while booting, so maybe ACPI isn't involved and it's me that needs to give their head a shake.
  Anyone know for sure?
  
  --
  I do not fail; I succeed at finding out what does not work.
14. Re:Precisely how... by Lumpy · 2014-03-17 07:22 · Score: 1
  
  Yuck QFP is a lot better far better pin density and easier to insert or remove safely.
  
  --
  Do not look at laser with remaining good eye.
15. Re:Precisely how... by Anonymous Coward · 2014-03-17 07:27 · Score: 1
  
  Point totally MISSED! The firmware running in the bios should be OPEN SOURCE - as in Coreboot. Modern PCs today don't NEED the bios of old as the hardware drivers get replaced anyway - with more open source.
  Furthermore, the whole UEFI fiasco could have been eliminated if we had a simple SWITCH on a pc to ALLOW writing to flash only when the user decides to update the bios - and I'm talking about a switch connected to the VLSI flash controller that can not be circumvented by software. A whole lot cheaper.
  Open Source 100%.
16. Re:Precisely how... by queazocotal · 2014-03-17 07:27 · Score: 1
  
  It is.
  It's one of the primary means that the kernel (of whatever OS) works out what hardware it's actually running on, and what it should setup.
  ACPI, PCI* configuration registers, and friends are all pretty much required in order to boot a random system successfully.
17. Re:Precisely how... by Anonymous Coward · 2014-03-17 07:28 · Score: 1
  
  "I could wait for someone to accept my changes into the Linux Kernel before I start testing it"
  How's that? If you propose your changes to be accepted to Linux, you should already have tested it, and I guess that's how it generally works right now?
18. Re:Precisely how... by blackiner · 2014-03-17 07:28 · Score: 2
  
  Isn't device tree pretty much declarative firmware? It has gained quite a bit of ground in the ARM on Linux world recently too. Seems like the solution already exists, it just need a bigger push.
19. Re:Precisely how... by amorsen · 2014-03-17 07:32 · Score: 1
  
  queazocotal has it right. ACPI prepares the hardware and tells the kernel where to find it.
  Of course on recent hardware EFI is taking over part of that. EFI is significantly more bloated than traditional ACPI BIOS.
  
  --
  Finally! A year of moderation! Ready for 2019?
20. Re:Precisely how... by jones_supa · 2014-03-17 07:33 · Score: 1
  
  Yes, it could be one solution.
21. Re:Precisely how... by sjames · 2014-03-17 07:37 · Score: 3, Informative
  
  He's talking about ACPI. That is, firmware that the kernel is expected to trust and run in it's own context after being loaded. That is quite distinct from bootstrap firmware that is expected to load and jump into the bootloader and then be inactive until the next boot.
  BTW, much of it is actually broken in various ways.
22. Re:Precisely how... by Florian+Weimer · 2014-03-17 07:47 · Score: 1
  
  The reference implementation of UEFI is open source, and some vendors use it as a basis for their firmware.
  Unfortunately, most Coreboot-using devices are tied down and do not allow non-interactive booting with custom firmware (if they allow custom firmware at all).
23. Re:Precisely how... by Anonymous Coward · 2014-03-17 08:03 · Score: 0
  
  Oh, I was actually thinking about the earlier stages of booting, involving just starting the kernel and all the stuff before that. ACPI is probably not used in those moments.
24. Re:Precisely how... by Anonymous Coward · 2014-03-17 08:06 · Score: 0
  
  Furthermore, the whole UEFI fiasco could have been eliminated if we had a simple SWITCH on a pc to ALLOW writing to flash only when the user decides to update the bios - and I'm talking about a switch connected to the VLSI flash controller that can not be circumvented by software. A whole lot cheaper.
  Open Source 100%.
  I don't think people advocating the return of the flash bios dip switch, or similar, realize how successful factor social engineering is in today's threat landscape. If that switch is available to the user, it would be fairly easy tricking most users into switching it. We can't build systems and standards only for the 1%.
25. Re:Precisely how... by LoRdTAW · 2014-03-17 08:06 · Score: 2
  
  I think you mean PLCC. It can be soldered directly to a board or socketed. And in the recent past it was the choice for socketing BIOS chips after DIP32 fell out of favor. QFP is quad flat pack which is always directly soldered to the board and not easily removed. I never seen a QFP socket outside of test fixtures.
  With the high density of todays boards, even PLCC is gigantic in terms of footprint so many have moved to smaller SMT packages. I have seen Intel motherboards using 8 pin SOIC chips, most likely on an I2C or SPI bus. You can buy sockets for them but no mainstream motherboard maker sockets them.
26. Re:Precisely how... by Anonymous Coward · 2014-03-17 08:16 · Score: 1
  
  I design hardware. I could wait for someone to accept my changes into the Linux Kernel before I start testing it, or I could write some firmware accessible through ACPI.
  Or; you could write a FOSS module interlinked with ACPI to coreboot and then everything would be free and you would have the ACPI you wanted. You would probably even find that the community would fix the bugs in the software you wrote for free and you would sell extra hardware.
  The thing is, that we want the full source to every bit. Anything less and the security risk is just too great.
27. Re:Precisely how... by drinkypoo · 2014-03-17 08:39 · Score: 1
  
  What Shutters wants is irrelevant. What he needs is open interface specifications to the hardware.
  One might reasonably argue that what one needs is the source to the firmware and the tools needed to apply it to the device. One's rebuttal might involve cost, but not "you don't need that".
  
  --
  "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
28. Re:Precisely how... by TechyImmigrant · 2014-03-17 08:42 · Score: 5, Interesting
  
  I'm talking about the device not the kernel.
  I can compile up my own kernel and test my device against it. But I can't go and deploy my device on the myriad computer/OS configurations out there if I need stuff compiled into the kernel. ACPI solves a problem. If your solution that replaces ACPI doesn't solve the problem ACPI solves while also solving the trojan-via-firmware problem, then it's useless. ACPI is horrible, and I'm all for replacing it with something better but I'm not seeing a proposal that does both.
  
  --
  I should use this sig to advertise my book ISBN-13 : 978-1501515132.
29. Re:Precisely how... by dargaud · 2014-03-17 08:43 · Score: 1
  
  Besides, ACPI is complete overkill for booting.
  Agree. I've written bootloader code and kernel drivers. All the bootloader really has to do is get the kernel in memory somehow and jump to it. Why can't you boot directly into the kernel you ask ? One reason is size; on many (embedded) systems, there are only a few Kb available for an executable on boot. The other is that the bootloader doesn't not change easily (it needs reflashing or is in some kind of ROM), allowing you to easily change the kernel.
  
  --
  Non-Linux Penguins ?
30. Re:Precisely how... by mspohr · 2014-03-17 08:54 · Score: 1
  
  He said "get rid of proprietary firmware".
  He didn't say get rid of all firmware.
  There is a difference.
  Open source firmware can be audited to see if the spooks are getting their hands on your data... not so with the proprietary stuff.
  
  --
  I don't read your sig. Why are you reading mine?
31. Re:Precisely how... by mspohr · 2014-03-17 08:56 · Score: 1
  
  He didn't say get rid of ACPI.
  He said get rid of proprietary firmware.
  You can have an open source ACPI (https://acpica.org/downloads) which you can audit to find the NSA evil bits.
  
  --
  I don't read your sig. Why are you reading mine?
32. Re:Precisely how... by mspohr · 2014-03-17 09:01 · Score: 2
  
  "What Shutters wants is irrelevant. What he needs is open interface specifications to the hardware."
  I think that's what he wants:
  "Declarative firmware that describes hardware linkages and dependencies but doesn’t include executable code is the best chance we have of real bottom-up security. The Linux device tree is a very good starting point."
  
  --
  I don't read your sig. Why are you reading mine?
33. Re:Precisely how... by tlhIngan · 2014-03-17 09:38 · Score: 2
  
  Besides, ACPI is complete overkill for booting.
  Agree. I've written bootloader code and kernel drivers. All the bootloader really has to do is get the kernel in memory somehow and jump to it. Why can't you boot directly into the kernel you ask ? One reason is size; on many (embedded) systems, there are only a few Kb available for an executable on boot. The other is that the bootloader doesn't not change easily (it needs reflashing or is in some kind of ROM), allowing you to easily change the kernel.
  ACPI is not just used for booting, it's used for controlling the customizations between systems. While the PC architecture has changed little in the way of memory maps since the 1980s, there are still things that various computer manufacturers do that no OS could ever program for.
  For example, PCI interrupt routing was completely up to the manufacturer in routing which IRQ when to which PCI IRQ. They were normally scrambled so you don't have all the cards using one IRQ line, but that information needs to be communicated between the BIOS and the kernel, otherwise the kernel has no way to handle PCI interrupts properly.
  You could define a data structure (which is what ACPI does), or you could program into the kernel every variation around for every motherboard, and hope that every mobo manufacturer out there updates the list and submits the patch.
  The other thing is, well, ACPI handles rebooting, shutdowns and suspend/resume. It tells you how to poke the hardware in various ways to accomplish the goal. It isolates the difference between hardware to the people who know it best - the hardware guys.
  Some of these things may be GPIO pins that change for routing convenience (to enable/disable wireless, for example, or for various status LEDs), power switches that control how the regulators operate, other settings and controls for various voltage rails and such.
  Every PC is not the same, each manufacturer might choose a different power regulator IC that requires different programming to turn it on and off, and ACPI is best to handle it. otherwise the kernel will have to have each and every variation in it programmed in.
34. Re:Precisely how... by nateman1352 · 2014-03-17 09:47 · Score: 3, Informative
  
  Honestly Shuttleworth's reasoning "Binary blobs can contain NSA exploits" is completely irrelevant to ACPI since ACPI byte-code can be completely de-compiled back in to the original source language making it very easy for security researchers to detect any funny business.
  Honestly the modern PC has several microcontrollers in it that contain code that the primary CPU never even sees. I personally would consider those a much bigger security threat than ACPI.
  So lets ask ourselves... why does he really want to get rid of ACPI? The answer is pretty simple, it going to take a lot of coding effort to get the Linux ACPI stack ready to fully support ACPI 5.0 and Connected Standby found on a lot of brand new laptops. This is just a feeble attempt to mask the fact that puring all his resources in dumb projects like Mir and Unity doesn't leave much left to keep up to date on new open PC platform standards.
35. Re:Precisely how... by Anonymous Coward · 2014-03-17 10:40 · Score: 0
  
  We can't build systems and standards only for the 1%.
  Like the fraction of a percent who will ever see BIOS malware?
36. Re:Precisely how... by amorsen · 2014-03-17 11:01 · Score: 1
  
  I do not think that anyone has a problem with interrupt routing tables or ACPI documenting how hardware should be poked. It could be laid out a little simpler perhaps, but that is mostly bikeshedding.
  One of the problems is that ACPI suddenly yanks the CPU out from under you and executes its own proprietary code, and the kernel or user space can do absolutely nothing about it.
  
  --
  Finally! A year of moderation! Ready for 2019?
37. Re:Precisely how... by nctritech · 2014-03-17 11:23 · Score: 1
  
  What people don't get is how PCI + ACPI have made modern computing possible, and how ARM systems suffer terribly precisely because no such equivalents to these exist in the ARM ecosystem (excluding some PCI bridges, but that's only one piece of the puzzle.) Before PCI (and ignoring EISA et al) all peripheral devices in a computer had to be configured manually. You had to know your Sound Blaster 16 used I/O port 220, IRQ 5, 8-bit DMA 1, and 16-bit DMA 5, and tell each one of your DOS programs or your Windows audio driver all of these things.
  
  Granted, some improvements came along the way, but they were troublesome and didn't always work as intended (Plug-and-Play ISA, for example). PCI was the first ubiquitous chipset-to-peripheral bus interface specification that provided all the information needed to figure out any given PCI device's hardware configuration with obnoxious amounts of detail (lspci -vv if you don't believe me).
  
  ACPI was brought in to clean up the other autoconfiguration-unfriendly interfaces that were lying around. Advanced Power Management was the biggest one that comes to mind, though things like MPS were pulled in also. A whole host of highly system-specific information comes in through ACPI and that's what makes it fairly easy to write a "run anywhere" operating system for systems that have ACPI and PCI. It's not perfect by any means, but without it there would be a bunch of proprietary ways to, say, send a "laptop lid was closed" event to the operating system.
  
  ARM does stuff like this with a pile of GPIO pins which are configured differently for every single bloody device that the otherwise identical ARM SoC is engineered around. You can thank ACPI and PCI in large part for keeping us from needing a specially tweaked OS kernel for every single model of PC that gets released. I'm glad they exist, however ridiculous they can seem at times.
38. Re:Precisely how... by TechyImmigrant · 2014-03-17 12:38 · Score: 2
  
  Declarative firmware only gets you so far. You can say 'Register to do X is at this address' but without software than knows what the hell to do with X you don't have a solution. Without an open interface spec, you can't write the software.
  That's why open interface specifications are a prerequisite for a bottom-up auditable code set.
  
  --
  I should use this sig to advertise my book ISBN-13 : 978-1501515132.
39. Re:Precisely how... by fisted · 2014-03-17 12:47 · Score: 1
  
  ACPI solves a problem
  And creates half a dozen worse problems in the process.
  
  --
  CLI paste? paste.pr0.tips!
40. Re:Precisely how... by fisted · 2014-03-17 12:50 · Score: 1
  
  where exactly is that free freedom? Oh, wait.
  
  --
  CLI paste? paste.pr0.tips!
41. Re:Precisely how... by TechyImmigrant · 2014-03-17 13:36 · Score: 1
  
  ACPI solves a problem
  And creates half a dozen worse problems in the process.
  Which bit of "ACPI is horrible, and I'm all for replacing it with something better" did you miss?
  
  --
  I should use this sig to advertise my book ISBN-13 : 978-1501515132.
42. Re:Precisely how... by Anonymous Coward · 2014-03-17 13:55 · Score: 0
  
  Honestly? Honestly? Are you really this stupid?
43. Re:Precisely how... by 0ld_d0g · 2014-03-17 20:33 · Score: 1
  
  Microcode has nothing to with any how you interact with the CPU though. ACPI However *is* the actual Interface. Hes saying lets label all the roads in this town and you're saying Mr. Smith never lets us play inside his yard.
44. Re:Precisely how... by nateman1352 · 2014-03-17 21:37 · Score: 1
  
  What exactly was stupid about my post? Take it you have never heard of ACPI Source Language or the Embedded Controller?
  Seriously where should you more worried about NSA exploits1) a de-compilable and OS visible byte code that controls thermal and power management or 2) An invisible micro controller firmware that converts signals from your scan matrix laptop keyboard into P/S 2 signaling?
  Seriously dude, I write firmware for a living... I know a thing or two about what it does and the state of Linux's ACPI stack.
45. Re:Precisely how... by Anonymous Coward · 2014-03-17 22:57 · Score: 0
  
  I design hardware. I could wait for someone to accept my changes into the Linux Kernel before I start testing it, or I could write some firmware accessible through ACPI.
  Or; you could write a FOSS module interlinked with ACPI to coreboot and then everything would be free and you would have the ACPI you wanted. You would probably even find that the community would fix the bugs in the software you wrote for free and you would sell extra hardware.
  The thing is, that we want the full source to every bit. Anything less and the security risk is just too great.
  And you have compiled your operating system yourself with a safe bootstrap compiler after reading every line of code? Doubtful but you might be one of the few
46. Re:Precisely how... by Anonymous Coward · 2014-03-17 23:03 · Score: 0
  
  Why would you need to wait for who to do what now? You realise...you realise you can compile the kernel yourself, with your own changes in it, right?
47. Re:Precisely how... by Lumpy · 2014-03-18 00:00 · Score: 1
  
  Correct, I mis-identified the package, I have QFP on the brain as I have been searching ebay for some old stock to fix an old DSP board, looks like I have to scrounge for some TMS320's on old boards.
  Some of the newer PLCC's have very dense pins on the surface mounted sockets. And honestly with I2C it is trivial to solder the chip on the board and simply provide a header to reprogram it. The funny part is a lot of the guys that really want socketed chips to use with their external programmer/reader do not realize that it is a lot easier and cheaper to use the on board solutions.
  
  --
  Do not look at laser with remaining good eye.
48. Re:Precisely how... by Anonymous Coward · 2014-03-18 01:25 · Score: 0
  
  great that you think acpi makes your job easier. you're free to build shit hardware
  that doesn't Just Work(tm). if you hardware designers would build shit
  that Just Works(tm) and bios that properly configures *everything*, you wouldn't
  need AML. arm land does just fine without it. what's your excuse?
  i even think you would find your live easier, as you don't have to deal with acpi.
  (i have no beef with acpi fixed tables. they're fine.)
49. Re:Precisely how... by Anonymous Coward · 2014-03-18 01:29 · Score: 0
  
  i think you're confusing acpi fixed tables and aml. the fixed tables do, or could do all of what you need. what everybody objects to is the aml crap. this is not needed. (and what has pci got to do with this anyway. it's not even discovered through acpi. it's always at the same fixed i/o port.)
50. Re:Precisely how... by TechyImmigrant · 2014-03-18 04:15 · Score: 1
  
  Not on target systems I don't control. Can I plug my new thing into the USB port of a Samsung phone? Not if I have to replace the kernel. The thing is locked.
  You can arrange your own machines how ever you like, but if you're building things to work on everyone's machines, then you need to test it in many contexts that you don't control.
  
  --
  I should use this sig to advertise my book ISBN-13 : 978-1501515132.
51. Re:Precisely how... by TechyImmigrant · 2014-03-18 04:18 · Score: 1
  
  I hate ACPI and avoid it at all costs. But I'm fully aware that if you removed ACPI, you would have to replace it with something. My Apple 2 has a scheme for mapping ROMs on cards into memory and calling them at boot time based on descriptors in the ROMs. It has to exist in some form.
  
  --
  I should use this sig to advertise my book ISBN-13 : 978-1501515132.
52. Re:Precisely how... by nateman1352 · 2014-03-18 04:56 · Score: 1
  
  It is true that the kernel is expected to load and run the ACPI bytecode in a trusted context... but your assumption that the BIOS is gone after the OS bootloader runs is inaccurate. SMM keeps BIOS code code resident forever and running at a higher privilege level than your OS kernel. And its impossible for your kernel to see what SMM is doing unlike ACPI which is pretty easy to inspect,
  Your BIOS already owns the platform and getting rid of ACPI won't change that, it will just make it more difficult to firmware engineers (like me) to support all OSes with 1 firmware image.
  I agree that ACPI sucks in a lot of ways, but you must admit that there is something to be said for a standard that has enabled WinXP (10+ year old OS) and brand new stuff like Win8.1 and all the countless Linux releases in between to run on practically any PC regardless of it being brand new or 10 years old.
  IMO the trend towards having special firmware for each OS is disturbing and limits the universal and reusable PC. A lot of this is being driven by Google and thier insistence that Chrome OS systems be shipped without Legacy BIOS or UEFI support (locked down coreboot that only accepts OSes signed by Google unless run in "developer mode", btw even in developer mode you can't install a new coreboot payload to enable UEFI or legacy BIOS boot).
53. Re:Precisely how... by sjames · 2014-03-18 05:42 · Score: 1
  
  I'm not as worried about ACPI from that standpoint as Shuttleworth is. I am worried about the way it is generally buggy and only actually tested on the latest Windows so often. Of course, ACPI should not be used as an excuse to make hardware incompatible with standards.
  I find SMM more concerning since it can obviously be used to produce a really nasty and hard to detect rootkit. At least ACPI has to reveal itself and offers the possability of running it in a sandbox..
  I have no sympathy whatsoever for any attempt to lock in a particular OS and enforce a signed kernel unless the user gets to decide what signing keys are valid.
  From everything I have seen, EFI is an abomination. The best thing that could happen is to erase all evidence it ever existed.
54. Re:Precisely how... by Anonymous Coward · 2014-03-18 06:02 · Score: 0
  
  TIL that ACPI is proprietary firmware, not a specification.
55. Re: Precisely how... by astar · 2014-03-18 06:26 · Score: 1
  
  Yah. But ARM has the little bit of cpu ram. Thus you start out without having to knowi anything about the busses like to the regular RAM. But there are specialized compilers for say AMD64 that produce programs that do not use RAM. But ...
  Grub2 just will not fit in the usual sized BIOS ROM. Mostly everything is easy quantity 1 plus some sort of trade offs in money and skill and time. Now go fix it quantity G this calendar year with everyone trying to stop you.
56. Re:Precisely how... by Agripa · 2014-03-18 07:38 · Score: 1
  
  It also contains the code executed in System Management Mode (SMM) which may handle tasks like legacy emulation and thermal control.
57. Re:Precisely how... by Anonymous Coward · 2014-03-18 08:34 · Score: 0
  
  Ain't no such thing. Freedom is very expensive, just ask any vet.
58. Re:Precisely how... by fisted · 2014-03-21 13:53 · Score: 1
  
  Which bit of "worse" did you miss?
  
  --
  CLI paste? paste.pr0.tips!
59. Re:Precisely how... by badkarmadayaccount · 2014-03-31 12:14 · Score: 1
  
  Does the new version solve problems in you opinion? Is it a good move? Just curious.
  
  --
  I know tobacco is bad for you, so I smoke weed with crack.
Source codes, legos, meccanos by Hognoxious · 2014-03-17 06:48 · Score: 3, Funny

Mark Shuttleworth calls for an end to proprietary firmwares
Well I call for an end to spurious pluralization, so there!

--
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
1. Re:Source codes, legos, meccanos by Anonymous Coward · 2014-03-17 07:07 · Score: 0
  
  Firmware is still a mass noun, but lego isn't anymore.
Silly Rabit by Anonymous Coward · 2014-03-17 06:48 · Score: 0

I never understand this from software perspective. How to you design a hardware that looks the same to software, all the time. I am suppose to make "new, faster, better, lower power, loser cost" hardware without changing anything?
1. Re:Silly Rabit by X0563511 · 2014-03-17 06:52 · Score: 2
  
  You don't have to.
  Just don't lock your implementation away and let people actually use it
  
  --
  For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
2. Re:Silly Rabit by ihtoit · 2014-03-17 08:15 · Score: 3, Insightful
  
  it's called reference frameworks. By the time you get to Userland, a Creative soundcard looks to the software identical to a Turtle Beach. This would be impossible without a reference. One obvious example is DirectX. What you want out of the arse end of the driver layer is a device interface that's compatible with DirectX. What happens between the driver layer and the hardware is entirely up to the manufacturer, but the DirectX compatibility is a certain requirement for even the slightest hope that you'll even get a peep out of it in Windows. And one of the reasons why the Linux driver model, at least from my own personal perspective, is horribly broken. Is there a reference framework for *anything* in Linux?
  
  --
  Political debates have me rolling my eyes so much I think I got optical whiplash. I should sue. - Foamy The Squirrel
3. Re:Silly Rabit by Arker · 2014-03-17 10:31 · Score: 1
  
  "Is there a reference framework for *anything* in Linux?" Yes, it's called Slackware.
  
  --
  =-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Friends don't let friends enable ecmascript.
4. Re:Silly Rabit by Anonymous Coward · 2014-03-17 11:14 · Score: 0
  
  But I love my Slackware box. With the exception of wireless cards, damn near everything is easy to install because all you have to do is edit a text file. Most of the system config files are well documented and pretty easy to fall. The wireless ones exist but it can still be a chore, especially if you don't have driver support.
  Otherwise, you can do anything on Slackware that you can do on any other linux system. The only thing it doesn't come with is a lot of bloat, and even that isn't true because the default full install is, frankly, bloated. You can trim that down big time and still have a fully functional system with office software, development software, and a slew of other things.
  So calling Slackware a framework isn't really fair.
  P.S. I suppose if you run some of the big, more cluttered and unnecessarily complex is areas that it just doesn't need to be, then I could see how Slacks K.I.S.S. philosophy may not work for you.
5. Re:Silly Rabit by tepples · 2014-03-17 14:58 · Score: 1
  
  Is there a reference framework for *anything* in Linux?
  For graphics there's KMS and DRI and Gallium. For audio there's ALSA. For printing there's CUPS. For scanning there's SANE. Etc.
6. Re:Silly Rabit by Arker · 2014-03-17 18:43 · Score: 2
  
  You misunderstand me, I love slack too. I was (somewhat tongue-in-cheek) pointing to its role as the standard implementation. Which unfortunately is really just a memory as for over a decade now other distros have insisted tenaciously on ignoring solid standards and everyone just reinvents the wheel, in ever more byzantine fashion each iteration.
  
  --
  =-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Friends don't let friends enable ecmascript.
7. Re:Silly Rabit by ihtoit · 2014-03-18 09:16 · Score: 1
  
  Yeah, most of those popped into my head one second after I hit "send"(!)... but speaking from my own experience, I've never been able to get a Winprinter working under CUPS (maybe I'm being 'tarded about it). As to graphics, I wasn't even going to pick up the whip if it wasn't an ATI/AMD or NVidia chip (OK, the drivers are proprietary for both, but I'm not bitter - I even managed to get Beryl running on an upgraded Rage Pro). Trying to get anything near "accelerated" on any other graphics chip was for me, like pushing a cow backwards up a staircase.
  
  --
  Political debates have me rolling my eyes so much I think I got optical whiplash. I should sue. - Foamy The Squirrel
8. Re:Silly Rabit by ihtoit · 2014-03-18 09:20 · Score: 1
  
  I love Zipslack... still use it on a positively ancient Dell CP (Pentium MMX) laptop. It's handy when all I want to do is type and don't need to be hearing the fan (which hasn't worked since ever and that isn't an issue anyway as the processor barely gets warm).
  
  --
  Political debates have me rolling my eyes so much I think I got optical whiplash. I should sue. - Foamy The Squirrel
Translated by Anonymous Coward · 2014-03-17 06:49 · Score: 1

"We at ubuntu ran into problems working with firmware type X and want to get rid of it and need an excuse, playing on fears tends to work, so let's use that"
1. Re:Translated by peppepz · 2014-03-17 08:21 · Score: 2
  
  Everybody runs into problems with ACPI. I've never seen it work properly, on any OS, on any machine that I've owned.
I can't see this happening. by allaunjsilverfox2 · 2014-03-17 06:49 · Score: 3, Funny

Perfect example would be dell bios. There is no way DELL would allow a USER into bios. Especially one that might cause issues that can't be condensed into auto-replies.

--
Restore the madness of youth's lechery
1. Re:I can't see this happening. by Anonymous Coward · 2014-03-18 01:40 · Score: 0
  
  The future of computing is perma-locked bootloaders and a big red "reboot/wipe to fix everything" button, with all your apps and data on the cloud, instantly synced back to you after the wipe.
  Nevermind that all your cloud data is infested with NSA viruses at this point...
Make Ubuntu work properly first by Anonymous Coward · 2014-03-17 06:55 · Score: 1

Shuttleworth has ambitious plans, but how about taking care of just the basic quality assurance of Ubuntu first. I am greeted with a bloated and laggy desktop (Unity) with constant "Ubuntu has experienced an internal error" popups. Launchpad has multiple reports of the silly bug of many laptops having the screen brightness adjustment go double steps because the brightness event is handled twice. Hibernation, a common feature of modern OS, is still disabled by default. I could go on.
1. Re:Make Ubuntu work properly first by Desler · 2014-03-17 07:00 · Score: 1
  
  But fixing bugs is hard!! Canonical is too busy code-churning for boring stuff like bug-fixing.
2. Re:Make Ubuntu work properly first by lgw · 2014-03-17 07:10 · Score: 2
  
  At Canonical, making Unity worse is job 1! It gets harder every release to make Unity worse than the last one, so it takes all their mental effort. Perhaps with open firmware, Unity could actually electrocute the user, opening a whole new realm of "worse".
  
  --
  Socialism: a lie told by totalitarians and believed by fools.
3. Re:Make Ubuntu work properly first by Anonymous Coward · 2014-03-18 02:19 · Score: 0
  
  Ubuntu works fine for me. Proceed with your stated plans, Mr. Shuttleworth.
What RMS has been saying all along. by Anonymous Coward · 2014-03-17 06:57 · Score: 5, Insightful

So people are just now figuring out that o'l fatty hippy beard Richard Stallman was right all along?
Color me fucking surprised! Any code you can't see can and will be used against you.
RMS says things that are uncomfortable and difficult but painfully true. Don't mistake is disinterest in your feelings (Or business model) as hostility.
1. Re:What RMS has been saying all along. by Anonymous Coward · 2014-03-17 10:01 · Score: 0
  
  Hear hear.
On the subject of Troy by K.+S.+Kyosuke · 2014-03-17 06:58 · Score: 1

I've been to Troy, there is not much left
Funny thing is, that's less due to Achaeans and more to Schliemann's "excavations". ;-)
(BTW, when did Shuttleworth decide to grow a kinkled beard?)

--
Ezekiel 23:20
Starts with one generic enough by gmuslera · 2014-03-17 07:03 · Score: 1

And if people start buying from that brand over rivals (or having country legislation forbidding not open enough and/or so backdoored hardware) it may move others to do the same.
Also, if a "hidden" functionality is exposed in major brands using that executable code to perform malware-like activities that brands should be punished in security aware circles. That won't reach the majority of people, but will be an start.
Possesion by MouseTheLuckyDog · 2014-03-17 07:09 · Score: 2

So how did RMS posses Shuttleworths body?
1. Re:Possesion by fahrbot-bot · 2014-03-17 07:13 · Score: 5, Funny
  
  So how did RMS posses Shuttleworth's body?
  There's an obscure clause deep down in the GPL ...
  
  --
  It must have been something you assimilated. . . .
2. Re:Possesion by Kjella · 2014-03-17 07:59 · Score: 3, Insightful
  
  It's part of the GPLv666 under the "Demonic Possession" section if you use the "or any later version" clause. I hear Stallman wrote the original in blood, he couldn't find any open source ink. And you really don't want to know how the toe jam is involved.
  
  --
  Live today, because you never know what tomorrow brings
3. Re:Possesion by ericloewe · 2014-03-17 09:06 · Score: 0
  
  And how does Stallman expect me to acquire the blood I need to produce the copy of the license I must distribute?
  If there's something worse than vendor lock-in, it's Free Software preacher lock-in.
4. Re:Possesion by triffid_98 · 2014-03-17 12:03 · Score: 1
  
  So how did RMS posses Shuttleworths body?
  
  A trojan in his ACPI firmware?
5. Re:Possesion by Anonymous Coward · 2014-03-17 17:47 · Score: 0
  
  Spill the blood of proprietary software developers. Duh.
Some context from a hardware perspective. by queazocotal · 2014-03-17 07:18 · Score: 5, Informative

Great - you don't want ACPI.
I'm looking at my Nokia n900 phone.
(merely because I happen to have a detailed understanding of the design).
Inside it, there are the following closed-source blobs running on turing complete processors.
LED controller firmware.
SIM java virtual machine
SIM raw firmware.
eMMC controller.
SD controller.
Hard-real-time modem controller.
Modem high-level engine.
Bluetooth CPU.
Wifi processor.
Main linux application processor
GPU.
I strongly suspect there is also an embedded processor in:
Power managment controller.
LCD.
Battery charge monitor.
GPS. (It's possible this is just an application running on the closed-source modem high level engine).
https://srlabs.de/rooting-sim-...
http://www.youtube.com/watch?v... (rooting SD cards)
http://www.youtube.com/watch?v... (battery firmware hacking)
Similar efforts have been done with reverse engineering the firmware of bluetooth devices, wifi.
The notion that you should only care about the code running on the CPU being open has always seemed really naive to me.
1. Re:Some context from a hardware perspective. by Anonymous Coward · 2014-03-17 08:16 · Score: 0
  
  Great - you don't want ACPI.
  I'm looking at my Nokia n900 phone. (merely because I happen to have a detailed understanding of the design).
  Inside it, there are the following closed-source blobs running on turing complete processors.
  LED controller firmware. SIM java virtual machine SIM raw firmware. eMMC controller. SD controller. Hard-real-time modem controller. Modem high-level engine. Bluetooth CPU. Wifi processor. Main linux application processor GPU. I strongly suspect there is also an embedded processor in: Power managment controller. LCD. Battery charge monitor. GPS. (It's possible this is just an application running on the closed-source modem high level engine).
  https://srlabs.de/rooting-sim-... http://www.youtube.com/watch?v... (rooting SD cards) http://www.youtube.com/watch?v... (battery firmware hacking) Similar efforts have been done with reverse engineering the firmware of bluetooth devices, wifi. The notion that you should only care about the code running on the CPU being open has always seemed really naive to me.
  Though I agree on the security implications of all this code, it's always seemed really naive to me that people open source would make an automatic difference. There are so many examples now of long overlooked OSS vulnerabilities, and a growing realization that proper security development lifecycle and stringent testing procedures with fuzzy testing etc. are more successful approach to catching vulnerabilities. And many closed source shops are better resourced to do this better, and with a more programmatic approach.
2. Re:Some context from a hardware perspective. by rahvin112 · 2014-03-17 08:29 · Score: 3, Informative
  
  There are many cellphones where there is an independent CPU running the cellular radio. This CPU runs a proprietary OS that runs has write access to all memory and can actually override the main CPU. In theory the radio CPU and OS could actually overwrite memory on the fly and redirect the kernel in completely transparent ways.
3. Re:Some context from a hardware perspective. by Anonymous Coward · 2014-03-17 08:42 · Score: 0
  
  Don't give him any ideas, he's already batshit enough.
4. Re:Some context from a hardware perspective. by ericloewe · 2014-03-17 09:09 · Score: 1
  
  I believe it's nearly all phones, if not all of them.
5. Re:Some context from a hardware perspective. by AmiMoJo · 2014-03-17 10:02 · Score: 3, Interesting
  
  Okay, but despite being Turing complete most of those devices could be contained by an open source firmware in a secure way. For example the LED controller is probably what, an I2C device? There is no way it could compromise anything with an even half way competent ACPI implementation. The battery monitor, LCD, GPS and probably a few others probably fall into that category too.
  For everything else you need a secure APCI implementation that is based on not trusting the firmware in those devices. Okay, the wifi firmware could intercept, modify or leak any packets, but at least with an open source ACPI implementation the damage could be limited, contained and perhaps detected. It's not perfect but it's a lot better than what we have now.
  
  --
  const int one = 65536; (Silvermoon, Texture.cs)
  SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
6. Re:Some context from a hardware perspective. by YoopDaDum · 2014-03-17 21:15 · Score: 1
  
  True, but at least on a PC the main CPU could protect itself against any device being an IOMMU. And in smartphones ARM also has an IOMMU IP (called SMU). I don't think it's commonly used yet, but on principle at least it is possible to hook any smart peripheral with an embedded processor (or several nowadays for a 4G cellular modem for example) to the SMU, and then the SMU to the SoC NoC providing access to the system memory. Then the user application processor (AP) can restrict any memory access from those devices.
  
  So even if such a smart peripheral is exploited, if it sit behind an IOMMU/SMU the AP can restrict to which parts of the memory it can access, just like a MMU provides such protection between processes. The peripheral, even if inside the SoC die, can be sandboxed.
  
  Is this how it is done today? I guess not. For SoCs, I'm not sure a lot of chip vendors pay for the additional SMU IP, unless they have another use-case that requires it (like supporting virtualization). And even if the hardware is there, I'm not sure it is actually used for security containment as I described. Could a linux expert comment on that for the PC world at least?
  
  Now of course an IOMMU/SMU will never protect against an embedded chip purposefully designed to be able to take control of the chip and access system memory without restriction, like the management chip on some Intel chips (vPro feature IIRC). But as you point out there are a lot of smart peripherals, and if we could at least mitigate exploits from them it'd be that many less potential holes.
  
  Last point, security always has a cost: someone needs to handle the IOMMU/SMU management to do the sandboxing. And a sandbox may prevent zero copy, requiring extra copying from the AP in some cases (to move data from AP reserved memory to/from a given device sandbox).
7. Re:Some context from a hardware perspective. by Anonymous Coward · 2014-03-17 21:33 · Score: 0
  
  Is this the case in dumb phones as well?
8. Re:Some context from a hardware perspective. by wed128 · 2014-03-18 01:28 · Score: 1
  
  Yes.
9. Re:Some context from a hardware perspective. by rahvin112 · 2014-03-18 04:56 · Score: 1
  
  I believe so as well but without reviewing every possible phone I wasn't comfortable making that prediction. I know almost every major SOC that produces radio chips does this because of fear that people would tamper with radio power levels but it's a major security hole that I'm sure is being exploited by groups like the NSA.
Shuttleworth wrote ... by tipo159 · 2014-03-17 07:18 · Score: 1

In ye olden days, a manufacturer would ship Windows, which could not be changed
What the hell is he talking about?
1. Re:Shuttleworth wrote ... by Anonymous Coward · 2014-03-17 08:51 · Score: 0
  
  You know, before Shuttleworth made Linux.
Stallman was right by SplashMyBandit · 2014-03-17 07:25 · Score: 0

Haha! Shuttleworth now agrees with Richard Stallman's assessment of the situation from thirty years ago.
Hopefully more IT leaders (and users!) also wake up to this.
If you can't control your device all the way down to the hardware, then bad guys will (and very sadly, bad guys now includes the NSA).
This is about ARM 64 bit Servers by Bill,+Shooter+of+Bul · 2014-03-17 07:27 · Score: 3, Informative

Its already been decided by the industry that its going to be ACPI.
And Canonical helped desgin it... with ACPI in it
http://www.businesswire.com/ne...
So I don't understand why Mark is suddenly against it. Sudden change of heart leading Ubuntu to be non compatible with other linux operating systems? Again? I don't get it.

--
Well.. maybe. Or Maybe not. But Definitely not sort of.
1. Re:This is about ARM 64 bit Servers by Anonymous Coward · 2014-03-17 08:24 · Score: 0
  
  So I don't understand why Mark is suddenly against it. Sudden change of heart leading Ubuntu to be non compatible with other linux operating systems? Again? I don't get it.
  Did you completely miss the news about the NSA? It turns out that instead of doing their job and defending us, they have been deliberately leaving holes in software and setting us up for our computers to be owned by the Russian mafia.
  Anyone who hasn't changed their attitude was either psychic or hasn't read and understood the implications of the fact that almost every bit of mainstream proprietary software has embedded backdoors which are easily discoverable and exploitable by almost every major government. Shuttleworth has every right to have changed his mind.
2. Re:This is about ARM 64 bit Servers by Bill,+Shooter+of+Bul · 2014-03-17 10:33 · Score: 1
  
  Yes, there are many fears of what a government could do to gain access. There is no way to avoid it currently. Saying ACPI has the potential for problems doesn't add anything new to the conversation that's been going on for years.
  I'm guessing someone just informed him what his company agreed to, or he's gone a bit crazy.
  
  --
  Well.. maybe. Or Maybe not. But Definitely not sort of.
3. Re:This is about ARM 64 bit Servers by Bill,+Shooter+of+Bul · 2014-03-18 04:41 · Score: 2
  
  Responding to my own post. Mark explained himself on Google plus (can't link to it directly but look for Jon Masters post about annoying a billionaire) :
  "SBSA did not specify ACPI or any other crapware, and we were happy to support a standards-based approach. I think it's a poor effort if we can't achieve the goal of standards in a more modern, secure, open way."
  So it appears that he supported one standardization effort, but it didn't specify ACPI. I don't know what the truth is as the relevant documents aren't public. Mark also claims that he did propose an alternative approach that would still allow a single kernel but not ACPI. Not sure how specific it was, or if it was anything beyond " Lets have the kernel guys do it!".
  
  --
  Well.. maybe. Or Maybe not. But Definitely not sort of.
4. Re:This is about ARM 64 bit Servers by Bill,+Shooter+of+Bul · 2014-03-18 05:01 · Score: 1
  
  https://plus.google.com/106265...
  
  --
  Well.. maybe. Or Maybe not. But Definitely not sort of.
Who cares? by Anonymous Coward · 2014-03-17 07:29 · Score: 0

We'll just all buy Chromebooks. Linux FTW!!!

When HP, Lenovo, Apple and Dell all fail it'll be Linux who will have brought them to their knees. We don't want Windows and we don't need Windows and we don't need Windows fanboys.
blobs? by Anonymous Coward · 2014-03-17 07:31 · Score: 0

He's pulling a Theo?
How original...
Re:Shuttleworth is incompetent 1% trash by Anonymous Coward · 2014-03-17 07:31 · Score: 0

Good thing he hasn't been CEO since March 2010, then.
Re:Let's guess what prompted this by Anonymous Coward · 2014-03-17 07:42 · Score: 0

You think that because the sales numbers say that all laptops sell with Windows installed. The fact of the matter is that at least 10% of all laptops out there are having Windows removed and replaced with Linux.
Because "Open Source" isnt an NSA vector by enigmatic · 2014-03-17 07:48 · Score: 1

Remember GnuTLS
1. Re:Because "Open Source" isnt an NSA vector by jones_supa · 2014-03-17 08:11 · Score: 1
  
  Yep. For truly secure and non-malicious software we need both open source and thorough code audits (à la OpenBSD).
2. Re:Because "Open Source" isnt an NSA vector by Anonymous Coward · 2014-03-17 08:51 · Score: 0
  
  Remember GnuTLS
  And forget about Microsoft TLS, since you will never be able to find out about the holes in that. 'cmon, it was the Linux guys catching a backdoor insertion attempt which first alerted people to the fact that such attempts are being made.
Re:Let's guess what prompted this by Anonymous Coward · 2014-03-17 07:53 · Score: 0

[citation needed]
Re:Let's guess what prompted this by Anonymous Coward · 2014-03-17 07:57 · Score: 0

Most laptaps these days are sold with OSX actually and once you already have a working unix desktop why would you downgrade to linux? Sounds to me like you're stuck in 2003.
That ship sailled in the early 90's by Wierdy1024 · 2014-03-17 08:06 · Score: 1

No escaping proprietary firmware now. I would hazard a guess that a laptop purchased today has firmware or firmware libraries from over 1000 teams.
You don't see them, because most are stored in roms and flash, and your OS doesn't need to know about them...
Re:Let's guess what prompted this by Anonymous Coward · 2014-03-17 08:07 · Score: 0

Linux is a massive failure on laptops. One of the big reasons is guessing what ACPI will do. (Another is power management, also linked to ACPI)
Huh. I read this on a Linux laptop and am responding using that laptop. I don't see any failure.
Translation by Anonymous Coward · 2014-03-17 08:14 · Score: 0

Vendors don't want our garbage OS so we need an excuse.
Shuttleworth is a publicity whore by Anonymous Coward · 2014-03-17 08:17 · Score: 0

Shuttleworth should have long ago done the right thing. He cheated us all out of it by saying we weren't interested. If people recall he even polled the community on this issue. If you ask me that was no excuse for not doing the right thing. Claiming credit now is just publicity whoring.
I stopped giving Shuttleworth's comments any real consideration long ago. He's taken action to invade our privacy (reporting activity to Amazon) and much more. There are people who are actually making a real difference. The Tor project, the Freedombox project, the Free Software Foundation, Richard Stallman, and even at least one company, ThinkPenguin (they sell free software friendly hardware and are concious of all the non-free bits still remaining everywhere despite compatibility with Trisquel, Parabola GNU/Linux, and other 100% free distributions).
This issue isn't just an ethical issue either like so many are bound to spout out. Stop letting emotion get the better of you. It's also a security, privacy, and usability nightmare. Do you really think a for-profit corporation is solely interested in freedom because it's the right thing to do? It might be one of the reasons, but it's definitely not the only reason. It's an ease of use issue that at least one CEO actually gets (ThinkPenguin).
Now we just need to get more projects and companies (looking at you Qualcomm, Intel, Broadcom, AMD, NVIDIA, and others) to follow ThinkPenguin's lead.
Don't we all by Anonymous Coward · 2014-03-17 08:25 · Score: 0

Isn't he the guy that takes Debian, sticks in some blobs and brands it Ubuntu?
More context by maestroX · 2014-03-17 09:03 · Score: 1

reminder for the list; signed code, tivoization, like sigma et. al. firmware support pretty much equals caveat emptor nowadays, I like to re^H^Huse the cpu/mobo for something useful oh well raspberry pi + sim anyone?
Re:Let's guess what prompted this by Anonymous Coward · 2014-03-17 09:05 · Score: 0

Shit. You better tell all those millions of Chromebook and Android users that linux is a flop! They'd never know otherwise!
in a good mood by Kevin+Fishburne · 2014-03-17 09:43 · Score: 0

Mark must have gotten laid recently. Or had lunch with Richard Stallman. Or...

--
Buy your next Linux PC at eightvirtues.com
Charles Stross? Is that you? by daboochmeister · 2014-03-17 10:07 · Score: 2

Your description of the GPLv666 with a "Demonic Possession" section sounds very worthy of a Charles Stross novel, in every respect. Kudos!

--
"Ahh! I see you're in that indeterminate Schrodinger state where - oh, uh ... never mind." Dave Bucci
I am in the bottom of the gates by Anonymous Coward · 2014-03-17 10:45 · Score: 0

All the register settings of a chip are normally open in a form of a spec (enough to invent the bullet, the gun, the foot, and shoot yourself many times over) Any yes some of these can damage the hardware if you program incorrectly. An initial driver from vendor is usually there as a starter for someone to write a full blown driver.
The problem is that people are not willing to spend the time and the effort to do this for a full product. They want canned (Linux) solutions.
Hardware companies make no money writing drivers. They are more than happy to let a third party do the work if they didn't have to support 1000 3rd party developers. The problem is that the support nightmare is not practical (specially for a small company)
Made me laugh by Anonymous Coward · 2014-03-17 12:13 · Score: 0

OK, +1 for the line ""Unity could actually electrocute the user...".
For once LOL is appropriate!
Chrome OS > OS X by tepples · 2014-03-17 15:05 · Score: 1

Most laptaps these days are sold with OSX actually
Citation needed that over 50 percent of laptops are MacBooks. Last year freaking Chrome OS outsold OS X (source: Google macbook laptop market share).
If your MS Win box goes into eternal reboot mode by Anonymous Coward · 2014-03-17 15:58 · Score: 0

... it is usually because of an ACPI problem.
Your awesome English... by Anonymous Coward · 2014-03-17 17:11 · Score: 0

//or the server running the cloud your SAAS app is running on//
Made me to read it four times....
The train left the station in the 2000s by Burz · 2014-03-17 20:25 · Score: 1

Escaping proprietary firmware.... http://www.coreboot.org/Welcom...
An OS can cope with hostile peripherals: by Burz · 2014-03-17 21:02 · Score: 1

In fact Qubes assumes they are hostile to a great extent already.
As long as one trusts the BIOS and other critical boot-time elements (i.e. ACPI), you have a very good shot at maintaining security with a system like Qubes and this is why Qubes users are expessing a lot of interest in Coreboot (open BIOS).
(Of course, one must also trust the CPU and chipset, but these are often provided by the same vendor which reduces the trust issue down to one party. And we're not even talking firmware or software here: Its hardware, which is further down the open source horizon, but someday.....)
Winprinter by tepples · 2014-03-18 11:33 · Score: 1

but speaking from my own experience, I've never been able to get a Winprinter working under CUPS (maybe I'm being 'tarded about it).
That depends on how you define "Winprinter". There used to be a concept of a "GDI printer" (or a "QuickDraw printer" during the classic Mac OS days), which relies on a rasterizer running on a PC to create a bitmap in some proprietary format and send it to the printer. More generally, they're called "non-PostScript printers", and they work fine under CUPS provided the manufacturer is friendly to the CUPS community. I bought my HP OfficeJet 4500 for exactly that reason: official support for printing and scanning through the HPLIP package. If your non-PostScript printer manufacturer doesn't ship a CUPS driver, blame the manufacturer.
1. Re:Winprinter by ihtoit · 2014-03-18 14:40 · Score: 1
  
  tried several bottom-shelf Lexmark inkjets, a couple of the Canon portables (BJ-10e and a BJC-80) and an HP Deskjet 320 as well. Ended up hooking up a Brother HL1030 (laser with manufacturer-supplied CUPS driver) and a HP Officejet 6210 MFD (ran through HPLIP), the other gear is gathering dust and spider colonies in a closet somewhere - can't even give the bloody things away...
  
  --
  Political debates have me rolling my eyes so much I think I got optical whiplash. I should sue. - Foamy The Squirrel
he's seen the light. by Finite9 · 2014-03-18 18:04 · Score: 1

Wow, is it true? This is the guy that was all about willingly making it easy for folk to install proprietary drivers for everything to ease adoption of Ubuntu. I remember all the forum discussions about that. Has he finally had a change of heart? RMS is likely having a moment of grim satisfaction right now.

--
"Everyone knows that vi vi vi is the number of the beast" -- Richard Stallman
Canonical is not a device manufacturer. by Anonymous Coward · 2014-03-19 18:04 · Score: 0

The companies actually buying components to manufacture PC and ARM devices wanting this would mean something. How many GPU chips support OpenGL, how about media chips with Theora and Vorbis support, or WiFi chipsets with Free Software drivers? Where are the consumers demanding this? Where is the hardware preferring these components? Companies like System76, Zareason, Think Penguin, etc. aren't demanding this from their suppliers, and their supplier's suppliers...
Is Mark proposing a copyright collective and funding a hardware unit?