Slashdot Mirror


UEFI Secure Boot Booted From Debian 9 'Stretch' (theregister.co.uk)

Debian's release team has decided to postpone its implementation of Secure Boot. From a report: In a release update from last week, release team member Jonathan Wiltshire wrote that "At a recent team meeting, we decided that support for Secure Boot in the forthcoming Debian 9 'stretch' would no longer be a blocker to release. The likely, although not certain outcome is that stretch will not have Secure Boot support." "We appreciate that this will be a disappointment to many users and developers," he continued, "However, we need to balance that with the limited time available for the volunteer teams working on this feature, and the risk of bugs being introduced through rushed development." The decision not to offer Secure Boot support at release leaves Debian behind Red Hat and Suse, making it the only one of Linux's three main branches not to support the heir-to-BIOS and the many security enhancements it offers.

168 comments

  1. RedHat by Aighearach · · Score: 4, Interesting

    This is an example of why 20 years later, I'm still running RedHat/Fedora/Centos family distros.

    I want all my FLOSS software to work. And I want business integration to work too. I don't want to have to choose them because they're not actually in conflict.

    1. Re: RedHat by Anonymous Coward · · Score: 0, Interesting

      I see what you're saying, but the problem I have with your reasoning is that we have seen total crap like systemd, PulseAudio, Gnome 3, Gtk+ 3, and Wayland come out of that camp/community. Those things have hurt my Linux experience more than anything else has. Systemd alone has caused me more headaches than anything MS or SCO ever did. In fact it was software from that camp which made me evaluate OpenBSD. It turns out that OpenBSD gives me everything good that GNU/Linux used to, but without so much awful software. OpenBSD has better security, too. That's why nearly all of my systems use OpenBSD now, and the remaining ones will soon be switched over.

    2. Re:RedHat by Anonymous Coward · · Score: 5, Insightful

      UEFI is a successor to BIOS in the same way that systemd is a successor to init. They both "solved" many problems that didn't exist to anybody but their creators and financial supporters. Nobody wanted them, yet somehow they were forced down our throats. Neither came from the bottom-up in grassroots-fashion; both came from the top-down in military-fashion. And yet here we are today, and they've both won.

    3. Re:RedHat by hackel · · Score: 0

      Ah, so you just want to sacrifice package quality and QA, while adopting dependency hell, all for "business integration?" That makes sense.

    4. Re:RedHat by epyT-R · · Score: 1

      Progresses towards what exactly?

    5. Re: RedHat by TWX · · Score: 3, Interesting

      Back in the late nineties I convinced my best friend to drop NetBSD and join us on Linux. At the time Linux seemed to be where all of the development was being done to make new hardware work where it didn't do so well in BSD. Now I'm wondering if it's time to reconsider the BSDs.

      --
      Do not look into laser with remaining eye.
    6. Re: RedHat by Anonymous Coward · · Score: 0

      Fool! don't you know BSD is dying? Netcraft confirms it.

      Aside from that, yeah you are dead right.

    7. Re:RedHat by networkBoy · · Score: 4, Informative

      I have to disagree, at least on the BIOS front.
      BIOS is a mess, hard to code for, pragmatically impossible to patch (how many users will actually do the updates).
      BIOS is a 16 bit system... it _needed_ to go away.
      UEFI may not be perfect, and it may not be the best delivery, but BIOS simply can't support what systems provide these days. > 512 byte disk sectors, SSDs, massive ram, BIOS is crap at all of them. Sure you can shoehorn some support in, but it's still crap. Most systems have been on EFI much longer than most people realize (mid 90's for big systems, 2000 for consumer), and uEFI since 05.

      --
      whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
    8. Re:RedHat by nyet · · Score: 1

      I see absolutely no benefit to UEFI. What does it have to do at all with "business integration"?

    9. Re:RedHat by zlives · · Score: 1

      by progress, i meant debilitating authoritarian control of government and corporations. which leads to monitization of the simplest processes thus furthering the economic divide between the rich and the consumed.

      That is almost same right? progress?

    10. Re:RedHat by whoever57 · · Score: 3, Informative

      Ah, so you just want to sacrifice package quality and QA, while adopting dependency hell,

      Begone, Troll!

      RedHat/CentOS haven't suffered from dependency hell for years. The adoption of YUM solved the issues.

      --
      The real "Libtards" are the Libertarians!
    11. Re: RedHat by fred6666 · · Score: 3, Informative

      PC hardware support is still years ahead on Linux, especially for stuff such as WiFi adapters and GPU.

    12. Re:RedHat by Anonymous Coward · · Score: 0

      If by "now" you mean at least the last few years. Yes

      New thing? RARR it's bad!
      Micro$oft thing? RARR it's bad!
      New Micro$oft thing? *has aneurysm*

    13. Re:RedHat by Megol · · Score: 2

      BIOS: 16 bit old design originally for booting from floppy drives, 32 bit support (partially) hacked in for some functions. System starts as a real-mode (8086 compatible) and have to be switched to 32/64 bit mode. Settings have been added ad hoc style over many years but still remains vendor specific. Extensions are hard to add. There aren't many standard interfaces for hardware and those that exist are mostly limited to hardware functionality from (at best) the 90's. Only 80x25 textmode is "guaranteed" (not really) to exist. Graphics modes are limited to VGA modes (assuming the graphics adapter supports them) or one can use an extension which often is of a bad quality (nobody uses it). It is a mess. Booting is done by reading a sector (normally 512 bytes) into memory and jumping to that memory block in real mode, that code is mostly enough to load the second stage bootloader. The BIOS doesn't know of filesystems so that is the responsibility of the boot block and/or the bootloader. Boot errors are handled by yet another mess of hacks. Power management is retrofitted over the legacy system as are other extensions. Emulation of legacy (PS/2) keyboard is a hack partially in hardware and partially in software, supports only the USB boot protocol and is a mess.

      UEFI: 32/64 bit design. Extensible. Standardized interface for settings. Abstracted graphics, network, storage etc. Supports FAT32, reads a 32/64 bit executable into memory from the boot media and jumps to that code with a rich API. After the boot loader is finished (it can load other files, initialize graphics modes etc.) it calls a function that essentially turns of the UEFI system allowing the system to continue booting under its own control. Faster. All implementations I know of supports emulating the legacy BIOS if needed.

      UEFI is bloated and I don't like the design. But saying that nobody wanted it is ludicrous. Everyone wanted something better than the legacy BIOS mess. If you want a grassroots approach then start coding an alternative but don't forget that you also have to have the support from X large companies (that have specific needs ans wants) and Y smaller ones (that just want something that works). You'd also need to support interfaces and standards that UEFI already does. Good luck.

    14. Re: RedHat by thegarbz · · Score: 0

      but the problem I have with your reasoning is that we have seen total crap like systemd, PulseAudio, Gnome 3, Gtk+ 3, and Wayland come out of that camp/community.

      That's not a problem with reasoning, that's a logical conclusion of it. If I plug a headset into a linux machine I expect it to just work and take over the audio feed. I don't expect to have to adjust anything play with anything. When I dock and undock hardware I expect the same, likewise with sleeping and hibernation. If a program crashes I expect the system managing the service to know, and not just assume it is still running because there's a PID. Speaking of it's nice knowing what is actually responsible for starting or stopping something. And when I buy hardware I expect to be able to use it in its entirety at peak performance without the cruft of 20 years of bad code getting in the way.

      Gnome 3 I have no defence for. That is just stupid. The rest of the projects were born out of the fact that computers should just bloody work.

    15. Re:RedHat by thegarbz · · Score: 1

      UEFI is a successor to BIOS in the same way that systemd is a successor to init.

      And both caused users who didn't have a clue to spew the garbage like you just did.
      They really are very much alike.

    16. Re:RedHat by hackel · · Score: 1

      Too little, too late. OP said he had been suffering under it for 20 years. I still have nightmares about rpmfind.net from when I had the unfortunate task of administering a Redhat system. While rpm/deb as a format may not be significant anymore, there's no arguing that the Debian Policy Manual itself is an extremely high standard that produces some excellent, high-quality packages.

    17. Re:RedHat by Anonymous Coward · · Score: 0

      You forgot to use 'modern' in that sentence, I'm not convinced without it.

      Anyway this crybaby is moving onto 'embedded' now that they run my distro and have more ram than my laptop. The rest is containered on alpine/devuan.

      Good luck with 'your' progress.

    18. Re:RedHat by Anonymous Coward · · Score: 1

      > BIOS simply can't support what systems provide these days. ... SSDs...

      Um. I have a non-EFI system that's happily running off an SSD. The fact that you don't know that SATA-attached SSDs look exactly like spinning rust disks to the underlying system makes you sound like a typical clueless systemd supporter. :(

      > ...massive ram...

      BIOS DGAF about ram > 640k or so. Sure, a BIOS can report and do some POST of all the RAM on the system, but that requires (just like every motherboard firmware in existence) custom work to work with the memory controller selected for the motherboard. And once the OS running on the system boots, neither EFI nor BIOS get involved in RAM access; if they _did_ get involved, RAM access would be _horrifyingly_ slow. In fact, OSs usually go to great lengths to undo a lot of garbage that both BIOSs and EFIs do on startup, as hardware manufacturers are horrifyingly bad at software.

      Using BIOSs on boards that support TBs of RAM is no more difficult than using BIOSs on board that support MBs of RAM. It's no more much custom work than one usually has to do to write new firmware for a new board.

      The only two good things to come out of EFI were GPT and SecureBoot. There no reason why GPT support _couldn't_ have been added to the various BIOSs (and GPT+MBR works just fine most of the time, and could be made to _always_ work just fine if it was the defacto standard way of doing things). SecureBoot would have been significantly trickier.

    19. Re: RedHat by sl3xd · · Score: 4, Insightful

      Systemd alone has caused me more headaches than anything MS or SCO ever did. In fact it was software from that camp which made me evaluate OpenBSD.

      There are a lot of good ideas in Systemd; overall, I don't disagree with a lot of the overall design goals.

      The implementation, on the other hand, is lacking. My own experience is that systemd has finally reached an "early beta" level of stability. (My desktop system boots correctly about half the time with Systemd. The other half of the time Systemd doesn't start up D-Bus... I can't even shut the system down cleanly, because <drum roll> you need d-bus to shut down with Systemd! Yay!)

      It's a shame systemd was pushed into production for most distributions years ago.

      --
      -- Sometimes you have to turn the lights off in order to see.
    20. Re: RedHat by ruir · · Score: 1

      I have installed FreeBSD, and will be evaluating OpenBSD too. Why OpenBSD vs FreeBSD?

    21. Re:RedHat by Anonymous Coward · · Score: 0

      I don't understand why this was modded down by anyone, maybe because a specific line of distro's was mentioned and a bunch of people had a knee-jerk "shill" reaction... If it works for you, it works. That's not an inflammatory statement, it's common sense.

      The whole post is a non-story anyway, so what? They decided not to ship a buggy UEFI implementation in a distribution known for it's almost stubborn dedication to stability and nothing else. Big. Deal. There's only a few thousand other distributions out there to choose from, some that even have commercial support and drivers for hardware made in the past ten years. As a Debian user I'd be more upset if they announced that a buggy, half-finished implementation of UEFI was going to make it into my choice server OS. It seems like if anything, it's just another case of Slashdot trying to make news out of nothing and unfortunately it seems like it worked. At least running uBlock Origin and several other extensions, I've effectively denied this ridiculous site any ad revenue from my visit...

    22. Re:RedHat by DRJlaw · · Score: 1, Informative

      Um. I have a non-EFI system that's happily running off an SSD. The fact that you don't know that SATA-attached SSDs look exactly like spinning rust disks to the underlying system makes you sound like a typical clueless systemd supporter. :(

      The fact that you ignore NVMe SSDs makes you sound even more clueless...

    23. Re: RedHat by Zaelath · · Score: 1

      Yeah, most recent install of a systemd operating system on a machine that was sold with linux:

      - Ubuntu 17.04, on an XPS 13 (sold with Ubuntu Linux 16.04 LTS)
      - Fresh install (wipe disk entirely, no dual boot)
      - Had to disable UEFI to get it to install (first attempt apparently installed ok, but there was "nothing to boot").
      - Booted in ok
      - Went to sleep that night
      - Couldn't connect to WiFi when it resumed the next day
      - Couldn't reboot without a long "systemd is fubar, I will wait 3 minutes for this non-responsive subsystem before shutting down" delay
      - WiFi came back on boot
      - WiFi never survives sleep

      Apparently such a common problem that someone on here lauded Systemd as an advance because this works:
      sudo systemctl restart network-manager.service

      Yeah, great. Windows is doomed.

    24. Re: RedHat by Aighearach · · Score: 2, Interesting

      I love systemd and PulseAudio.

      Gnome 3 I don't use, I use xfce and the world is wonderful and the desktop never changes. I don't actually use a "desktop," but I do like a traditional window manager and task bar.

      Gtk+ 3 is irrelevant to me. Even when I'm writing Gtk-based GUI apps I can just use the parts of the API that were in Gtk 2 if I want. There is nothing wrong with Gtk+ 3 though, the way there is with Gnome 3 and the needless shifting of paradigms. Gtk mostly behaves the way it always has, from the application perspective or the user perspective.

      Wayland isn't something I'm ever likely to use. I guess I'm weird but I like having a networked window system. X isn't going away from serious platforms, even as other options are added.

      If you can't manage a system because of systemd, if you actually have serious business-y high maintenance system needs and you can't learn how to have it be easier under systemd, then maybe it is actually just you? If OpenBSD does everything you need, this is probably more of a grooming issue than a technical issue.

    25. Re: RedHat by Aighearach · · Score: 1

      I tried BSD again for a workstation about a decade ago and it was serviceable but a PITA.

      If you have a reason to switch, just do it. Software worth running runs everywhere.

    26. Re:RedHat by Aighearach · · Score: 1

      Progress might look different if you had software freedom.

    27. Re:RedHat by Aighearach · · Score: 1

      What do you have against shoehorns, anyways? It is really hard to find a good shoehorn these days. When I was a lad I could buy a nice brass one at a yard sale for a dollar. Now they want over $20, and they only have plastic.

      People don't remember the old days, "I bought a new hard drive, but my BIOS is old so I had to format it as two drives. Now I can't find anything and I'm always out of space even though I still have space. :(" Sorry grandpa, you have to buy a new computer every year because digital shoehorns are proprietary.

      I remember those days, I don't care if UEFI is imperfect. Can I still choose my OS? Yes? Is it standardized? Yes? Sold!

    28. Re:RedHat by epyT-R · · Score: 1

      Come on, those fallacies are getting old now.

    29. Re:RedHat by epyT-R · · Score: 1

      You will care when most oems start shipping their systems with secureboot forced on.

    30. Re:RedHat by Aighearach · · Score: 2

      Nope. I won't care at all.

      People will publish on the internet news about which manufacturers are unfriendly to software freedom, and it will be easy to select hardware that meets my needs.

      The trend is the other direction. These days I can even program a Texas Instruments microcontroller using emacs and gcc and a cli flash tool. Hardware isn't getting locked down, it is getting thrown wide open!

    31. Re: RedHat by Anonymous Coward · · Score: 0

      There are a lot of good ideas in Systemd; overall, I don't disagree with a lot of the overall design goals.

      What was wrong with plain text files for configuration instead of SystemD and its Microsoftesque approach to logs? One of the draws of GNU/Linux and all of the *nixes has been plain text configuration files which are easy to edit, easy to version control, and not in need of Poettering meddling.

    32. Re:RedHat by Anonymous Coward · · Score: 0

      > 512 byte disk sectors, SSDs, massive ram, BIOS is crap at all of them

      They could've fixed all that by having a real OS with all its advantages as the "bootloader" (think LinuxBIOS/coreboot) instead of some crippled over-complicated over-engineered piece of shit like EFI.

      The reasons for pushing EFI were purely political -- a pipe dream of turning the PC into a closed system like the embedded garbage, and kicking out all those dorks that pretend to boot linux and *bsd on their "designed for windows" laptops.

    33. Re: RedHat by Anonymous Coward · · Score: 0

      There are a lot of good ideas in Systemd; overall, I don't disagree with a lot of the overall design goals.

      What was wrong with plain text files for configuration instead of SystemD and its Microsoftesque approach to logs? One of the draws of GNU/Linux and all of the *nixes has been plain text configuration files which are easy to edit, easy to version control, and not in need of Poettering meddling.

      How do you read an ASCII or a database file?

      Answer: You use a program specifically designed to read an ASCII or a database file.

      Oh please don't say this is not the Unix way since Unix has binary files (ie. utmp and wtmp) as well and I guess you have not worked on an AIX system.

    34. Re: RedHat by enrique556 · · Score: 1

      To be fair, even windows has trouble waking from sleep and re-enabling all of its components. I've got a recent-ish pcie soundcard and an old pci tv card that don't wake up in linux OR windows. Things are improving under linux and at some point sleep/resume will be superior under linux for any component that is at least a year old, because open source.
      Also, did you try sleep/resume on ubuntu 16.04 LTS before you zapped it? Laptops are kinda hard for any OS to get 100% working drivers for - maybe you should've stuck with the LTS. Upgrading a windows install on a laptop is more likely to be troublesome, especially if you're upgrading to a just-released version.

    35. Re: RedHat by Zaelath · · Score: 1

      Yes, to be completely fair I had Windows 10 on it previously, and at one point they released an update that made the OS blue-screen every time you connected to a WiFi router... so not perfect. It was eventually patched, but that required a dongle to be able to download. Even uninstalling the patched driver and installing an older replacement was reversed by Windows "healing" until MS decided to release a patch themselves.

      I didn't run 16.04 on it because I don't care for Unity, I'd rather run Windows, plus if I was going to double down on an old version I'd probably try and get CentOS 6 running ;p

      My real bugbear is that people can suggest systemd is superior because you can restart a service to fix one of it's faults.. like you couldn't always restart a service to fix Linux. Rebooting is sure as hell not my first instinct on Linux like it is in Windows.

    36. Re: RedHat by Zaelath · · Score: 1

      How do you read an ASCII or a database file?

      Answer:
      ASCII -- with just about anything you like, there's thousands of ways to read/write/edit it
      database -- by converting it to ASCII

      Are you trying to suggest AIX is easier to use than Linux?

    37. Re:RedHat by Anonymous Coward · · Score: 1

      There is nothing that prevents adding support for NVMe to the old BIOS. It's just a simple int 13h handler.

    38. Re: RedHat by Anonymous Coward · · Score: 0

      Because, like yours, it's a parroted knee-jerk reaction response to anything "bad" happening in the Linux world. Someone heard OpenBSD was most secure, so that it'll be -- oblivious to the actual state of OpenBSD, it's lack of SMP support, no virtualization, and above all completely false approach to security through correctness of code while, at the same time, that premise is constantly being broken by all the new security vulnerabilities they introduce in the software they NIH-ed in house. Vulns in opensmtpd, openhttpd, doas and latest, LibreSSL (which btw always has issues that are found in OpenSSL, very rarely doesn't, and now increasingly has issue OpenSSL doesn't.

      It's all valiant effort, open source and good stuff to pick and choose from (like OpenSSH), yes. But keep it real, OpenBSD as a whole ecosystem is NOT a valid replacement for anything. Maybe DOS.

    39. Re: RedHat by Anonymous Coward · · Score: 0

      The concept of UEFI is great, but GNU/Linux distributions have lagged in implementing it. Being limited to Red Hat or Suse is not an option.

    40. Re: RedHat by mvdwege · · Score: 1

      Ubuntu 17.04,

      You can stop right there. Ubuntu has done enough to damage the reputation of Linux on its own, with its stupid NIH mentality which leads it to half-assed implementations of things that work fine on other distros.

      --
      "I know I will be modded down for this": where's the option '-1, Asking for it'?
    41. Re:RedHat by LienRag · · Score: 1

      Doesn't this means that Secure Boot as much as UEFI is moot now and that only Coreboot or Libreboot have any legitimacy on a computer?

    42. Re:RedHat by Aighearach · · Score: 1

      First of all, most of my "computers" are not Intel systems, so your idea that they represent everything with "legitimacy on a computer" is absurd. It is impossible for it to be true, and it is silly and stupid on its face.

      Next, go and read the link. Understand it from a technical perspective. Then come back and talk to us here. You've come to a place where people understand those scary words you linked to.

      I'll give you the short version of what it says:
      1) Intel is not very responsive to people who, in their own words, "were not so polite about our viewpoint"
      2) If you turn on remote administration features, your device can be remotely administered and local bugs become remote bugs. Who knew?! But like your link says, "This flaw is remotely exploitable only if you have AMT turned on." The remote aspect is what is moot, because unless you're a company with an army of full-time sysadmins you shouldn't even have considered turning it on. And if you do have them, then there is a patch.
      3) Local exploits are not a serious threat to serious people or serious systems, because you don't run random third party code on important systems. Yeah, if you download windows executables you will get p0wned. This doesn't change that. The this is, if you're intentionally running dangerous code, you get p0wned anyways, even without something like this that escalates the problem.

      This is an exploit in the same way that ability to run a BIOS firmware update with normal administrator permissions was an exploit. It is a reason some people might buy a different brand, but some of us were already buying a different brand.

      In the 90s people who wanted a nice BIOS would buy one. I personally really liked Phoenix BIOS, though most systems shipped with American Megatrends. The internet says they're both making UEFI systems these days, along with others. Also, the internet lists a bunch of non-intel CPUs that are supported, such as ARM, which is more popular than not just Intel, but the whole x86 family.

      If you're vulnerable to local exploits... you're already vulnerable to local exploits! No bug is actually required for that, assuming you have permissions to do useful work on the computer.

    43. Re: RedHat by Zaelath · · Score: 1

      While I agree with you, I can't say much different for RedHat either...

      I was just looking for a "should work on this hardware" distro that had a decent GUI (Gnome's not perfect either), got any suggestions?

      Also.. does anyone in the Linux world have a touchpad driver that even attempts to do palm detection? I'd be ok with something as coarse as "If I've just typed anything at all, disable the god damn touchpad for 2 seconds".

    44. Re: RedHat by mvdwege · · Score: 1

      I find straight Debian to work just fine, and I have had no problems the few times I tried Fedora either.

      As for palm detection, the standard X driver and XFCE work on my hardware (Clevo W950JU).

      --
      "I know I will be modded down for this": where's the option '-1, Asking for it'?
    45. Re: RedHat by Zaelath · · Score: 1

      Sadly the XPS13 has a Broadcom WiFi chip that requires the non-free drivers, so Debian is out.

      Fedora is a bit too cutting edge for me, I've only ever used it when the hardware is too new to load RedHat/CentOS.

    46. Re: RedHat by Anonymous Coward · · Score: 0

      Debian has the non-free Broadcom driver broadcom-sta-dkms. You need to include non-free and contrib in your sources.list, then you can apt-get it.

  2. What's the point? by Anonymous Coward · · Score: 0

    If you want to dual-boot Linux and a recent version of Windows (the only reason to leave SecureBoot turned on), you're running an Ubuntu derivative.

    1. Re:What's the point? by Anonymous Coward · · Score: 0

      Really? The ONLY reason to turn on Secure Boot is Windows? That makes no sense. The reason to turn on Secure Boot is that it is more secure.

    2. Re:What's the point? by Anonymous Coward · · Score: 1

      Of course. And the reason for the PATRIOT Act is it's patriotic.

    3. Re: What's the point? by Anonymous Coward · · Score: 0

      And yet a couple of posts up, people complain about it being useless change, etc..

    4. Re:What's the point? by gweihir · · Score: 1

      For variable values of "secure". In fact you have to be doing pretty dumb things to get any security benefit from "secure" boot and if you are doing these dumb things you will be compromised anyways, just by a different path. There is actually no good reason to turn on "secure" boot.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    5. Re:What's the point? by Anonymous Coward · · Score: 0

      I take it you have never interacted with humans?

    6. Re:What's the point? by Anonymous Coward · · Score: 0

      I take it you've never tried reasoning without ad hominem?

    7. Re: What's the point? by Miamicanes · · Score: 1

      Is dual-booting even *viable* anymore? I did it for years, but sometime around Windows 7, Windows just became too damn hostile to dual-boot... as in, every time I booted into Windows after running Linux, Windows insisted on taking a sidetrip to analyze/fix its ACLs that could take anywhere between 30 seconds and 3 days to complete (usually, 2-7 minutes).

      The sad truth is, if you have files larger than 4 gigs, there really *isn't* a filesystem anymore that's natively and robustly supported by both Windows and Linux that both can safely share and use directly. Using ext2/3 with Windows is almost data-suicidal, Linux pretends exFAT doesn't exist, and Windows throws a tantrum if some other OS touches a NTFS partition it regards as its own (not to mention, Windows imposes requirements on NTFS that NTFS *itself* doesn't... it's *really* easy to accidentally get a NTFS filesystem into a state that works fine in Linux, but causes Windows to throw a tantrum (max path length, allowable characters in filenames, etc.).

      For a quick & easy example, dual-boot into Linux, and back up your Windows c: drive to a tarball. Now untar it into a path like '/oldWinC', boot into Windows, and try to access those files. Windows will bitch about path length, because its IE cache files max out the allowable path, and restoring them to a subdirectory instead of '/' causes the limit to be exceeded.

    8. Re: What's the point? by Anonymous Coward · · Score: 0

      That's not a bug built by M$, it is a feature.
      I read from a book, "Overdrive" that Lotus was killed by M$ because Lotus123 spreadsheet application would crash on M$ DOS. While MS Excel works flawlessly. Turns out there were undocumented API's in DOS (API's which were intentionally built by M$) that needs to be called before launching the application. Lotus123 didn't know of that secret API in DOS hence the crashing bug and the dwindling of their sales. Lotus closed shop which left many programmers unemployed.

    9. Re: What's the point? by Anonymous Coward · · Score: 0

      The sad truth is, if you have files larger than 4 gigs, there really *isn't* a filesystem anymore that's natively and robustly supported by both Windows and Linux that both can safely share and use directly.

      I've been using UDFS for years on my external hard drives. On Microsoft platforms, read/write support for UDFS requires Windows 7 or newer, but who uses XP/Vista anymore... Linux has of course supported read/write UDFS for longer than that.

  3. risk of bugs being introduced through rushed devel by Anonymous Coward · · Score: 0

    Microsoft wouldn't let such a small thing stop them.

  4. Why doesn't this stop the show? by Anonymous Coward · · Score: 0

    People should say: How are they working around this?

    1. Re:Why doesn't this stop the show? by Narcocide · · Score: 1

      The vast majority of hardware vendors do not enable secure boot by default anyway. If you bought a prebuilt machine from an OEM that does, you'll have to learn to turn it off, but such vendors were already doing their best to stop new users from installing Linux so it's not like many of them would have succeeded anyway. Debian's action here is triage, nothing more.

    2. Re:Why doesn't this stop the show? by Anonymous Coward · · Score: 0

      And if you want to dual boot Windows and debian? What do people do?

    3. Re:Why doesn't this stop the show? by Anonymous Coward · · Score: 0

      What's to work around? Only an infinitesimal minority dual-boot Debian and Windows.

    4. Re:Why doesn't this stop the show? by DaHat · · Score: 0

      How horrible that consumers are given the choice as to which OEM to buy from, and can presumably determine if a new machine meets their needs or not in this regard... if they even know what secure boot is and why they might care.

      but such vendors were already doing their best to stop new users from installing Linux

      Why would those OEMs care which OS an end user installs after they've got their money? "Oh, you installed Linux? I'm sorry, we only support Windows on the machine. *click*"

    5. Re:Why doesn't this stop the show? by Narcocide · · Score: 1

      They usually are more careful about who they buy hardware from.

    6. Re:Why doesn't this stop the show? by Narcocide · · Score: 1

      Why would those OEMs care which OS an end user installs after they've got their money?

      I don't think you're really this stupid. I think you're just being paid to claim to be this stupid. Get fucked, shill.

    7. Re:Why doesn't this stop the show? by DaHat · · Score: 1

      I don't think you're really this stupid.

      Why not educate me then?

      I think you're just being paid to claim to be this stupid.

      In fact I am getting paid right now... but that has nothing to do with this post. Some of us have day jobs which involve more than just venting on the internet. Try again.

      Get fucked, shill.

      Believe it or not, people can disagree without being a shill.

    8. Re: Why doesn't this stop the show? by Anonymous Coward · · Score: 0

      Windows doesn't require secure boot to boot

  5. What about Non-Secure Boot UEFI Boot? by Zombie+Ryushu · · Score: 4, Interesting

    Several of my boards support UEFI boot, or CSM Boot but the Secure Boot Portion can be turned off (or is absent in the case of one of my boards. I have one of the few early boards that has UEFI but not Secure Boot.). You can do a UEFI Boot without SecureBoot Verification like Macs do,

    1. Re:What about Non-Secure Boot UEFI Boot? by Anonymous Coward · · Score: 1, Informative

      UEFI works fine. It will only be SecureBoot that runs on top of it that could cause problems.

      If you'll be running Debian on a server or virtual machine, this will not be a problem.
      If you run Debian on "Windows 7" era or older desktops, it will also run fine.

      Where you need to be careful is with newer desktop systems mainly designed to run Windows.

      If there is a "Windows 10 compatible" sticker for example, you won't be able to run Debian on it.
      If there is a "Windows 8 compatible" sticker, you may or may not be able to, depending on what that OEM decided to do, so will need a bit of research.

      Microsoft declared that to get the Windows 10 compatible certification, the system must have SecureBoot and there must not be a way to disable it.

      In order to get the Windows 8 certification, Microsoft said the system must have SecureBoot, but they didn't yet dictate that it can't have an option to disable it. It was mostly up to the OEM, and I'm not aware of too many that did this.

      Where SecureBoot can not be disabled, your only options are to use boot loaders signed by Microsoft, or to upload your own private keys into SecureBoot and sign your own boot loaders.
      If that doesn't sound like an option for you, you'll want to avoid those OEM vendors.

      Note that you can still have working Debian desktops with the latest gen hardware, but you'll need to either build a system from parts, or find an OEM vendor that specifically caters to Linux.

    2. Re:What about Non-Secure Boot UEFI Boot? by Anonymous Coward · · Score: 1

      Where SecureBoot can not be disabled, your only options are to use boot loaders signed by Microsoft, or to upload your own private keys into SecureBoot and sign your own boot loaders.
      If that doesn't sound like an option for you, you'll want to avoid those OEM vendors.

      Note that you can still have working Debian desktops with the latest gen hardware, but you'll need to either build a system from parts, or find an OEM vendor that specifically caters to Linux.

      Can't we just start murdering MS/Intel/etc board members and corporate officers until they stop the BS?

    3. Re:What about Non-Secure Boot UEFI Boot? by tepples · · Score: 4, Insightful

      If there is a "Windows 10 compatible" sticker for example, you won't be able to run Debian on it.
      If there is a "Windows 8 compatible" sticker, you may or may not be able to, depending on what that OEM decided to do, so will need a bit of research.

      Source?

      Microsoft required x86 and x86-64 PCs with the "Windows 8 compatible" sticker to ship with Secure Boot on but let the owner turn it off in the UEFI configuration form. Microsoft eased this requirement for x86 and x86-64 PCs with the "Windows 10 compatible" sticker: they must ship with Secure Boot on but configurability is up to the preference of the manufacturer. In either case, even if Secure Boot can be turned off, that doesn't mean that things like backlight brightness, audio, WLAN, Bluetooth, and suspend will work correctly.

    4. Re:What about Non-Secure Boot UEFI Boot? by Anonymous Coward · · Score: 0

      > If there is a "Windows 10 compatible" sticker for example, you won't be able to run Debian on it.

      This statement is utterly wrong. I have a Debian Jessie system up and running on such a laptop next to me right now.

    5. Re:What about Non-Secure Boot UEFI Boot? by jabuzz · · Score: 2

      So one presumes that "Windows 10" compatible certification that my Surface Book has is er imaginary then? I say because you can turn off secure boot if you want. You get a big red unlocked padlock thing on the boot screen, but it *DOES* work.

      I ended up turning it back on when I realized that Ubuntu supports secure boot, so there was no need to actually turn it off. Which reminds me I need to fix the grub font's because right now they are tiny.

    6. Re:What about Non-Secure Boot UEFI Boot? by ncc74656 · · Score: 1

      Microsoft declared that to get the Windows 10 compatible certification, the system must have SecureBoot and there must not be a way to disable it.

      How is it, then, that I got Gentoo up and running on my notebook, and had SystemRescueCD booting from flashsticks before that? It shipped with Win10, but there's an option to disable secure boot that works as it should.

      (If it makes any difference, the machine's a Dell Latitude 7370. The main holdup on putting Gentoo on it wasn't secure boot, but the puny 120GB SSD that shipped with it.)

      --
      20 January 2017: the End of an Error.
  6. I take issue with the definition by Anonymous Coward · · Score: 1

    I wish we would stop using the word Security when we really mean Vendor Lock-in.

    1. Re:I take issue with the definition by TWX · · Score: 1

      From that vendor's point of view, that is security. Financial security.

      --
      Do not look into laser with remaining eye.
    2. Re:I take issue with the definition by sl3xd · · Score: 2

      It's vendor lock-in when secure boot is forced upon the hardware's owner.

      It's important to recognize that the owner is not necessarily the person posessing the hardware.

      Consider, for a second, the point of view of an IT department: There's a perfectly reason to prevent users of hardware from reinstalling an OS on top of hardware owned by the university/company/organization.

      --
      -- Sometimes you have to turn the lights off in order to see.
    3. Re: I take issue with the definition by Miamicanes · · Score: 1

      Why, exactly, should the user of a company laptop who travels for business *not* be allowed to boot Linux from his own USB drive when he's in his hotel room at night? Almost all companies encrypt their drives with Bitlocker, so it's not like there's a real risk of company data being compromised by malware... without the key, it's *impossible* for malware running under an externally-booted OS to read the decrypted data or write subtle changes to the company's boot drive (at worst, it might render it unbootable until the OS gets reinstalled).

      Back when I traveled a lot for business trips, I just bought a drive & drive caddy on ebay for my company-issued Dell D600, and swapped in *my* drive when I was in the hotel room or on the plane. IMHO, it was win-win for everyone... for all intents and purposes, I was traveling with two de-facto different computers whose OSes never directly crossed paths, because they were never in the computer simultaneously. My stuff never went anywhere near the company's HD, or endangered the sanctity of its data. If I'd been forced to take my own laptop too, you can *bet* the company's laptop would have been the one at risk of theft/breakage in my checked baggage...

    4. Re:I take issue with the definition by Anonymous Coward · · Score: 0

      Man, you can't own a computer. The computer owns you.

    5. Re: I take issue with the definition by Anonymous Coward · · Score: 0

      Why, exactly, should the user of a company laptop who travels for business *not* be allowed to boot Linux from his own USB drive when he's in his hotel room at night?

      Because it's not his fucking laptop, it is his work's laptop. Why don't you do your fucking job instead of trying to run Linux on every computer you don't own?

  7. "Heir-to-BIOS?" by hackel · · Score: 3, Informative

    Lot of FUD being spread in this article. Debian certainly supports UEFI, the *true* "heir-to-BIOS." Secure Boot was a terrible technology from the start. It's disappointing that they weren't able to finish work on it in time, but this certainly isn't the huge issue this article is making it out to be. The majority of Debian installations are going to be in virtualised environments in the first place. Desktop users are probably going to be on testing or another Debian derivative. It kind of makes me angry that Ubuntu didn't contribute this code to Debian straight away, but what can you do.

    1. Re:"Heir-to-BIOS?" by bws111 · · Score: 4, Interesting

      Why is secure boot a 'terrible technology'? We use it quite successfully here. What are the problems with it?

    2. Re:"Heir-to-BIOS?" by Anonymous Coward · · Score: 0

      Do you mean to say that testing branch supports UEFI secure boot? How do you install it?

    3. Re:"Heir-to-BIOS?" by gweihir · · Score: 1, Insightful

      1. It is not "secure" at all
      2. It is DRM, i.e. makes it less "your" hardware

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    4. Re:"Heir-to-BIOS?" by Anonymous Coward · · Score: 0

      the historically prudish sticks-in-the-mud at debian (who can seemingly create controversy out of thin air) probably had ulcers at the thought of getting microsoft's blessing and signing (they are the ones who hold the keys for secure boot) for their boot code.. my guess this has nothing to do with 'not enough time' to develop the feature.. they just flat out DON'T WANT TO.

    5. Re:"Heir-to-BIOS?" by nyet · · Score: 1

      Why do you use it? To what end?

    6. Re:"Heir-to-BIOS?" by bws111 · · Score: 4, Interesting

      1) Why? Because you said so? Exactly what is insecure about it?

      2) Exactly the opposite in our case. We sign our own images. The only code that will run is stuff signed by the appropriate key. That means users, hackers, and especially rogue admins don't get to install their own backdoors. Our stuff remains OURS, not THEIRS. As it should be.

    7. Re:"Heir-to-BIOS?" by Anonymous Coward · · Score: 1

      It's a solution in search of a problem--trying to turn PCs into locked down chains of trust when every PC OS (even OpenBSD) has security vulnerabilities. Let alone the whole rootkit issue. But, sure, let's sign a vulnerable Linux kernel and then for near ever have it as a usable replacement for a "secure" up to date kernel because it's signed. That's "Secure Boot".

      Seriously, while Secure Boot isn't useless, there's a lot of other things that are a lot more useful and without the hassle of trying to obtain special permission to get your kernel approved. Or to just disable Secure Boot because it's 99% hassle. At least with Windows 10, where you can force updates and invalid previous kernels quickly it makes sense. That's not Linux land. Or Windows 7 land. Or really any other OS land.

    8. Re:"Heir-to-BIOS?" by bws111 · · Score: 4, Interesting

      We use it to protect important machines (servers, automation controllers, etc) from tampering by external or internal parties. Of course, it is not secure boot by itself that does that, it is in combination with SELinux and IMA. Secure boot, however, is a key component (does no good to have your kernel verify signatures before running things if the kernel itself is not trusted).

    9. Re:"Heir-to-BIOS?" by bws111 · · Score: 1

      The whole 'rootkit issue' is WHY you use secure boot and associated technologies (like IMA). And if you actually know what you are doing, you will be using remote attestation to ensure that you are not, in fact, using a known vulnerable by signed kernel.

    10. Re: "Heir-to-BIOS?" by Anonymous Coward · · Score: 0

      If rogue admins are such a big problem at your company, then secure boot and UEFI aren't going to fix that. Who says they don't also have a copy of the keys?

    11. Re:"Heir-to-BIOS?" by bws111 · · Score: 2

      The Microsoft signing thing is only a convenience, it is certainly not required. We sign all our own stuff, MS is not involved at all.

    12. Re: "Heir-to-BIOS?" by bws111 · · Score: 3, Insightful

      Nobody said they WERE a big problem, just that they COULD be a big problem. If you can't acknowledge that, clearly you don't know much about security. Which I guess is rather obvious since you ask that dumb question about the keys (hint: no single person has the key, and the people who DO have a portion of the key are quite a bit higher than 'admin', and the whole key never exists anywhere but tamper-resistant hardware).

    13. Re:"Heir-to-BIOS?" by nyet · · Score: 1

      If your machine can be exploited to the point where the kernel can be replaced, preventing the kernel from being replaced is not going to help you.

    14. Re: "Heir-to-BIOS?" by Anonymous Coward · · Score: 0

      If rogue admins are such a big problem at your company, then secure boot and UEFI aren't going to fix that.

      Not the original poster but...

      Sounds like it's not a problem since they're proactive and DO something about it before it becomes a problem. Rogue admins do exist, even if it's not a problem NOW, who is to say the next hire won't be a problem? Also you have the problem of rogue USERS as well. SecureBoot at least stops this for us.

      Who says they don't also have a copy of the keys?

      At my company at least, to get the SecureBoot keys, you need two people to open the safe that stores the private keys. One of which is the manager and another one of the senior admins.
      One set of keys for desktops/laptops and another set for servers. The keys get loaded when new systems come in and back in the safe they go.

      Keeping private keys secure isn't really as hard as you think it is, just requires some thought and effort.

    15. Re:"Heir-to-BIOS?" by bws111 · · Score: 2

      What system do you run where an admin can't replace a kernel? Or do you just stick your head in the sand and pretend there is no such thing as an inside job? Or that there is no way (social engineering) to get an admin to do something stupid, intentionally or not?

    16. Re:"Heir-to-BIOS?" by nyet · · Score: 1

      If that admin has the ability to replace the kernel (maliciously or otherwise), the whole system can be compromised even if the kernel cannot be replaced.

    17. Re:"Heir-to-BIOS?" by bws111 · · Score: 3, Insightful

      How? I notice a common thread of the anti-secure boot people is that they just make statements with nothing to back them up.

    18. Re:"Heir-to-BIOS?" by tepples · · Score: 1, Informative

      We sign our own images. The only code that will run is stuff signed by the appropriate key.

      Provided that the manufacturer has deigned to let you trust your own key as opposed to Microsoft's key. As of Windows 10, Microsoft is allowing PC makers and motherboard makers to prevent the user from turning off or otherwise reconfiguring Secure Boot. And if you had intended to work around this by building your own computer, good luck finding parts from which to build a compact laptop.

    19. Re:"Heir-to-BIOS?" by Anonymous Coward · · Score: 0

      The code has to be signed by a key that's in the computer's SecureBoot keystore. Can you think of a non-Microsoft key they can expect to be on most people's PCs?

    20. Re:"Heir-to-BIOS?" by bws111 · · Score: 2

      Manufacturers don't have to 'deign' anything. There are loads of manufacturers who are only too happy to sell you servers, etc for something other than Windows. That is not going to change. In addition many manufacturers will build you a workstation to your requirements, you just have to make it worth their while to do it. Your statement is pure FUD.

    21. Re:"Heir-to-BIOS?" by gweihir · · Score: 1

      A fascinating level of naivety and non-knowledge you have there. Sounds very much to me like you made a really stupid decision and now cannot admit it.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    22. Re: "Heir-to-BIOS?" by gweihir · · Score: 0

      You cannot secure your operation against your admins. Anybody with any real security knowledge knows that. It is just not possible. Of course, a lot of wannabees think differently, but they are clueless about the actual realities. Often it is management that fantasizes they can buy cheap admins because they do not have to trust them. The actual reality is that a competent admin can do anything. (That there are many incompetent admins is another story...)

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    23. Re: "Heir-to-BIOS?" by Anonymous Coward · · Score: 0

      Anything can be hacked, so don't bother with any layer of security.

    24. Re:"Heir-to-BIOS?" by thegarbz · · Score: 1

      Yeah so? They could already do something like that by including some hardware that prevents the computer from working and not providing drivers. There's nothing new here in terms of what is being taken away from consumers.

      The only difference is that now there's a standard interface to do so, one which a manufacturer of general hardware would likely not get caught dead doing, especially given the recent trends for many of them to offer you choice of software platform.

    25. Re:"Heir-to-BIOS?" by Anonymous Coward · · Score: 0

      How? I notice a common thread of the anti-secure boot people is that they just make statements with nothing to back them up.

      No, you're simply being intentionally obtuse and/or willfully ignorant. You attempt to deflect and avoid by insisting those replying to you essentially provide a basic CS course for you.

      If you are unable to understand or comprehend how a machine that's not under your full control is less secure, I can only conclude you suffer either extreme ignorance or willful obtuseness driven by some personal agenda.

    26. Re:"Heir-to-BIOS?" by thegarbz · · Score: 1

      It's amazing how much is said without saying anything. I assume that while insulting the GP you yourself have run out of knowledge and thus refuse to answer his question. I expected nothing more.

    27. Re:"Heir-to-BIOS?" by hackel · · Score: 1

      No, sorry, just that this is where it will land first when it's ready. I don't use it so I don't actually know the status on testing.

    28. Re:"Heir-to-BIOS?" by Anonymous Coward · · Score: 0

      They're using their own signed kernels to audit their own servers and only for certain servers (probably servers for confidential data). I doubt that other people are going to be running that company's stuff on their machines.

    29. Re:"Heir-to-BIOS?" by Anonymous Coward · · Score: 0

      Somehow GPP's "they" got misread as "users", when it clearly means "Debian".
      Debian can't self-sign their code and expect it to work on your computer with SecureBoot.

    30. Re:"Heir-to-BIOS?" by Anonymous Coward · · Score: 0

      The whole 'rootkit issue' is WHY you use secure boot and associated technologies (like IMA).

      Awesome. Because a rootkit couldn't possible run the kernel in a VM. Yep, Blue Pill doesn't exist.

      And if you actually know what you are doing, you will be using remote attestation to ensure that you are not, in fact, using a known vulnerable by signed kernel.

      Yep, we all know that a rootkit couldn't fake or otherwise spoof to bypass remote attestation. Yep, totally impossible. Seriously, once a system is sufficiently owned, you can't trust anything it says. You can try to poke and prod it (Rootkit Revealer was a neat approach), but so long as your adversary basically has a copy they can work at home with and run all the same tools, they can work around each one of your little traps.

      Seriously, though, this is not what 99% of Secure Boot is for. It's for Grandma to be "protected" from "malicious" Linux installs or her Surface Tablet. Except, that didn't work out so well because people don't really want Surface Tablets (en mass). If the use case was things like companies, you're still mostly boned because companies themselves don't like the hassle of dealing with guaranteeing the integrity of every bit of software on every system, especially when every couple years they're pushed into paying massive upgrade fees.

      Finally, schools and libraries mostly want/need a system that can be reimaged regularly. But then the image itself needs updated regularly and the anti-virus/malware needs kept up to date (thankfully Windows Defender makes that simple instead of relying upon schools/libraries having the upgrade money for some commercial solution). The actually day to day risk is most a userland software that causes headaches for the day (or days) until reimaging can be done, not the whole system stack (since you don't need to be a headache to go as far as messing with the kernel).

      The 1% that are left? Great that they've got Secure Boot. It'll help them. Of course, just being generally up to date, firewalls, disconnecting devices, and physical security are 99% of the answer. But, yea, that extra Secure Boot probably won't hurt.

    31. Re:"Heir-to-BIOS?" by Anonymous Coward · · Score: 0
    32. Re: "Heir-to-BIOS?" by Anonymous Coward · · Score: 0

      You cannot secure your operation against your admins.

      Sure you can. It's just that if you do, you fall squarely into "it's not really your computer".

    33. Re:"Heir-to-BIOS?" by Anonymous Coward · · Score: 0

      Where do I get this server-laptop you are talking about?

      I mean, that must be what you mean when you mention server motherboards to someone who says good luck building your own laptop.

    34. Re:"Heir-to-BIOS?" by Anonymous Coward · · Score: 0

      > That means users, hackers, and especially rogue admins don't get to install their own backdoors. Our stuff remains OURS, not THEIRS. As it should be.

      Everything you listed helps organisations prevent unauthorised access/modifications to systems by users. However for the end user, e.g. Joe Blow developer with a laptop, what is the value proposition of Secure Boot? He has to do extra work to generate the secure boot keys and enrol them in UEFI. He has to do extra work to sign his images.

      The end benefit is... someone else can't modify his system. This could also be accomplished with a UEFI Setup Password and FDE (LUKS or similar), with far less effort.

      Secure Boot only helps organisations trying to lock down access to a computer. For the average user, it provides no benefit. The truly privacy conscious aren't using UEFI anyway, because the UEFI implementation from all major vendors is closed-source and has not been independently audited, they're using coreboot and similar.

    35. Re:"Heir-to-BIOS?" by Anonymous Coward · · Score: 0

      I really wish I had an employer such as microsoft that would pay me by the hour to post on slashdot to defend their tactics

    36. Re: "Heir-to-BIOS?" by gweihir · · Score: 1

      The answer of a truly clueless moron. What are you, 12 years old?

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    37. Re: "Heir-to-BIOS?" by gweihir · · Score: 1

      Or rather your sysadmins are not sysadmins and cannot help you in case of real problems anymore. A sure way to kill yourself economically in the long run and completely stupid. So, no, you cannot do that.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    38. Re:"Heir-to-BIOS?" by gweihir · · Score: 1

      You wish. But I do not give out free security consulting when it is a) real work and b) the targets are not capable of understanding it anyways.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    39. Re:"Heir-to-BIOS?" by mvdwege · · Score: 1

      I find the ranting of homeless psychotics also hard to understand. That still doesn't make them right.

      --
      "I know I will be modded down for this": where's the option '-1, Asking for it'?
    40. Re:"Heir-to-BIOS?" by gweihir · · Score: 1

      And your point is? Do you have a problem with anybody but you actually having skills and insights?

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    41. Re:"Heir-to-BIOS?" by mvdwege · · Score: 1

      Do you have a problem with anybody but you actually having skills and insights?

      I don't.

      --
      "I know I will be modded down for this": where's the option '-1, Asking for it'?
  8. Debian by Anonymous Coward · · Score: 0

    When are they going to finally get rid of systemd?

    1. Re:Debian by Narcocide · · Score: 1

      Well, it only took them one whole release to realize avconv was a mistake, but there is a lot more funding behind systemd, so I worry it may take longer.

      Of course, if enough people start migrating to Devuan before Stretch is released, maybe they'll get a clue quicker.

    2. Re:Debian by TWX · · Score: 1

      They did. It's called the Devuan fork. I've been using it on some multimedia PCs at home and so far so good.

      --
      Do not look into laser with remaining eye.
    3. Re:Debian by HiThere · · Score: 1

      Unfortunately, Devuan has a lot less infrastructure support than Debian. That takes time and money to build. So far development on Debian largely works automatically with Devuan, so that hasn't caused much trouble, but it will predictably cause more trouble ahead as divergence inevitably means more work to make packages work for both. Even more lamentably there are reports that systemd is causing intentional incompatibilities. This isn't just a repeat of information that isn't as good as second-hand, so don't take it seriously, but merely as something to watch for.

      That said, if Devuan makes a go of things, there will be a need for more volunteer developers. Do your skills fit?

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    4. Re:Debian by Etcetera · · Score: 1

      Even more lamentably there are reports that systemd is causing intentional incompatibilities. This isn't just a repeat of information that isn't as good as second-hand, so don't take it seriously, but merely as something to watch for.

      I suspected/expected that would occur. Any pointers to background there?

    5. Re:Debian by HiThere · · Score: 1

      Sorry, I made an editing mistake, and there's no way to correct a post if you don't notice it until after you've posted. That should have read:
      This is just a repeat of information that isn't as good as second-hand, so don't take it seriously, but merely as something to watch for.

      That's what happens when you do a re-write and aren't really careful.

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
  9. Get the f*ck over systemd by Anonymous Coward · · Score: 1

    Can't believe adults rant so much, so often about systemd. Get over it, for goodness sake...

    1. Re:Get the f*ck over systemd by TWX · · Score: 0

      You're saying that we shouldn't be disappointed that something that worked fine was replaced with something that is broken?

      Why don't you go back to Windows? Seems that OS is more in-tune with your attitude.

      --
      Do not look into laser with remaining eye.
    2. Re:Get the f*ck over systemd by Anonymous Coward · · Score: 0

      You're saying that we shouldn't be disappointed that something that worked fine was replaced with something that is broken?

      You have a very strange definition of "working fine" when it comes to sysvinit. Most of what people consider "sysvinit" is really just a shitton of barely working scripts. Guess you've never had an issue with a system that wouldn't finish booting because your Oracle DBA has an init script that doesn't exit/background itself. Oh and it won't finish starting because the network isn't up and the application needs to talk to the DB server. That's always fun.

      Now don't get more wrong, I think systemd is a solution looking for a problem, I'm just not sure which problem it's trying to solve.

      Face it, they both suck balls, you are just more familiar with a particular ball sucker.

      Meanwhile the rest of us who have shit to do, just fucking cope with the newest pile of shit heaped in.

    3. Re:Get the f*ck over systemd by Etcetera · · Score: 1

      Face it, they both suck balls, you are just more familiar with a particular ball sucker.

      No. People writing shell scripts that don't know how to suck balls.

      Init scripts aren't complicated, but different Unices (even within the SysV tradition) have solved various problems different ways. Beyond lack of shell knowledge, most of the really horribly written init scripts I've seen as an RH admin have been from Debian-focused writers who aren't familiar with RH conventions. RH makes stuff super easy with /etc/init.d/functions to do most of what you need. And most stuff that isn't included is dealing with some weird issue with the daemon you're starting to begin with.

      Admittedly, maybe that lack of cross-distro drop-and-replace was a reason to standardize on something, but that's kind of what LSB guidelines were there for. We didn't need systemd, let alone allllllll the other shit that systemd forced down our throats in its Giant Leap Forward.

    4. Re:Get the f*ck over systemd by TWX · · Score: 1

      That's basically where I'm at with it. I was familiar with Slackware's init, I was familiar with Debian's init. Can't remember off of the top of my head but I believe one used SysV, the other used BSD. Either way, not that complicated, easily fixed by hand if necessary.

      If a replacement for the various fragmented inits was limited in its scope then I would be fine with such a replacement. Trouble is, this seems to have taken the kitchen-sink approach, throwing everything in whether it's needed or not, and worse, it seems to have broken the tenet that everything is editable with a text editor and some patience.

      --
      Do not look into laser with remaining eye.
    5. Re:Get the f*ck over systemd by Etcetera · · Score: 1

      That's basically where I'm at with it. I was familiar with Slackware's init, I was familiar with Debian's init. Can't remember off of the top of my head but I believe one used SysV, the other used BSD. Either way, not that complicated, easily fixed by hand if necessary.

      If a replacement for the various fragmented inits was limited in its scope then I would be fine with such a replacement. Trouble is, this seems to have taken the kitchen-sink approach, throwing everything in whether it's needed or not, and worse, it seems to have broken the tenet that everything is editable with a text editor and some patience.

      Yeah. There's very little in the "replace with config" space that couldn't already have been accomplished with other tools, or by writing their own. That's essentially what you already have with superservers like xinetd or even DJB's daemontools, which can successfully be hung off the edge of an otherwise opaque rest-of-the-init-system. Most importantly, that provides ISOLATION and a defined interface without demanding changes everywhere else.

      If someone wanted a new fancy parallel superserver for socket systems, that's fine. If some of "/etc/rc" and "/etc/rc.sysinit" (in RH-land) was to be optimized or rejiggered or (heaven forbid) replaced with a busybox-like super binary that does a bunch of stuff, fine. But those two things are orthogonal and should have been treated as separate projects.

      The ironic thing is that a big chunk of what systemd was originally sold as ("Faster boot speeds!") was achievable with what should have been a third project in RH-land: Following Debian in changing /bin/sh to dash instead of bash.

      Oh well.

    6. Re:Get the f*ck over systemd by TWX · · Score: 1

      While I appreciate faster boot speeds, this seems less of an issue with Linux than with Windows, and has been achieved as you pointed out with shells like dash and through other techniques like actually paring-back hard on both the kernel and the daemons on the system to what's truly necessary versus being a general-purpose system. It may be harder to pare-back on package-based systems like those using RPM and dpkg, but that's mostly due to sometimes excessive declared dependencies that may or may not be truly necessary for specific functions.

      Boot speed in the VM world may be more of a issue since cloud users might want to create or destroy instances dynamically, but if a cloud platform is singular in purpose then that's even more reason to pare-back on the daemons and kernel modules. There's simply no reason to have general-purpose tools if they're never going to be used and arguably constitute security risk.

      --
      Do not look into laser with remaining eye.
  10. No loss by gweihir · · Score: 1

    Since "secure" boot is anything but and basically just DRM on steroids, it does not matter much in real life. The only thing to do about it is to make sure to buy hardware were it can be turned off.

    As to "heir of BIOS", well maybe. At this time it is still usually a step back. For example, I have an utterly stupid Acer UEFI implementation that cannot boot from memory stick in either mode. It can boot from USB CDROM (go figure), so for a new installation I have to keep an USB CDROM burner and some rewriteables around. That is not impressive at all. It also keeps its UEFI boot files in a non-standard location, just to make things more interesting.

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    1. Re:No loss by bws111 · · Score: 1

      It is amazing how often you can repeat the same nonsense without ever offering a single shred of evidence.

    2. Re:No loss by Anonymous Coward · · Score: 0

      What's truely amazing is how willing you are to suck cock without even getting compensated for it. A true lackey if there ever was one.

    3. Re:No loss by gweihir · · Score: 1

      As I happen to be an expert, if you want evidence you will have to pay for my time. But go head, be as stupid as you like to be.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    4. Re:No loss by Anonymous Coward · · Score: 0

      You aren't an expert in fuck all. You're just an old piece of shit who's too incompetent and lazy to defend your own bullshit opinions.

      But "go head," illiterate old fuckstain, be as stupid as you like to be. All things being equal you'll be dead soon and the world will be free of your ignorance forever.

    5. Re:No loss by Anonymous Coward · · Score: 0

      gweihir: "You know, I'm like a very smart person"

      Internet: "uhhhhh, yeah.. "

    6. Re:No loss by gweihir · · Score: 1

      Fascinating. You should seek professional help, there is something seriously broken in your mind.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    7. Re:No loss by gweihir · · Score: 1

      If that is what you read from my comment, then you are definitely not a smart person, because that is not what I said.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    8. Re:No loss by mvdwege · · Score: 1

      As I happen to be an expert,

      Actual expertise is inversely correlated with the vehemence with which it is announced. You haven't actually shown any indication that you have enough expertise to tell Grandpa where the on/off button is, so I'll take your statements with some salt.

      --
      "I know I will be modded down for this": where's the option '-1, Asking for it'?
    9. Re:No loss by Anonymous Coward · · Score: 0

      Whose a good boy?? Whose a good boy ??!! You are !

    10. Re:No loss by gweihir · · Score: 1

      And who is hugely immature? That would be you, obviously. Fascinating how some people can utterly disgrace themselves. It also makes it obvious why you post as AC.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  11. Secure Boot has No Lawful Purpose by Anonymous Coward · · Score: 1

    Secure Boot has no lawful purpose, at all. It is designed only to prevent you using your device how you want.

    1. Re:Secure Boot has No Lawful Purpose by Anonymous Coward · · Score: 0

      It prevents you from using MY device how you want to. Yes I want my employees to use their devices in the manner that is prescribed by our policies. That includes not reinstalling the OS on it.

    2. Re:Secure Boot has No Lawful Purpose by Anonymous Coward · · Score: 0

      By being the employer you already have leverage so you don't need Secure Boot. All you need are penalties for breaking policies.

    3. Re: Secure Boot has No Lawful Purpose by Anonymous Coward · · Score: 0

      So add a password to BIOS, lock the boot sector and configure it to boot straight from hdd with no alternatives.

    4. Re: Secure Boot has No Lawful Purpose by Anonymous Coward · · Score: 0

      UEFI IS the BIOS. We also have preboot authentication configured as well. Without our keys, even replacing the boot disk, it won't work. So thank you for telling me to do what we already do. UEFI/SecureBoot does it better than legacy BIOS passwords do. BIOS passwords don't protect against hard drive swaps you know. UEFI and SecureBoot does.

    5. Re:Secure Boot has No Lawful Purpose by Anonymous Coward · · Score: 0

      We have penalties for it as well. Maybe you've never heard the phrase "defense in depth". That's what we are doing. It might not be 100% secure, but it's sure better than hope and a prayer, which is what you are suggesting.

    6. Re: Secure Boot has No Lawful Purpose by Anonymous Coward · · Score: 0

      You worry about harddrive swaps? You have bigger issues than a boot environment..

    7. Re: Secure Boot has No Lawful Purpose by Anonymous Coward · · Score: 0

      Again it's not something that is an issue, but devices do get stolen. If we can make the device useless to a thief, all the better. Most of our laptops are used by telecommuters. You wouldn't believe all the shit that can happen to laptops.

  12. "Secure boot" only ever had one mission by whoever57 · · Score: 4, Insightful

    The mission of "Secure Boot" is not to secure any computers, but to secure Microsoft's revenue stream.

    Yes, you may be able to disable it on your desktop, but will this situation continue? Remember those Surface RT tablets?

    --
    The real "Libtards" are the Libertarians!
    1. Re:"Secure boot" only ever had one mission by Anonymous Coward · · Score: 0

      Nobody bought Surface RT tablets with the intention of running Linux on them. Stop lying..

    2. Re:"Secure boot" only ever had one mission by Anonymous Coward · · Score: 0

      Exactly my sentiment. Remember that UEFI attack where a miscreant can store a rootkit on the EFI partition itself? Made me ponder on what the real purpose of UEFI Secure Boot is. This UEFI thing is backed by huge corporations with a different agenda, "To lockdown machines from Linux". It is good that Debian boycotts this UEFI thing, seems they really knew what's going on behind the scenes of this UEFI mess.

  13. and amd / intel / supermicro have the server marke by Joe_Dragon · · Score: 1

    and amd / intel / supermicro / others have the server market that is very non windows to deal with as well.

  14. Beggars can't be choosers by tepples · · Score: 2

    How horrible that consumers are given the choice as to which OEM to buy from, and can presumably determine if a new machine meets their needs or not in this regard

    Provided they have the budget for a new machine in the first place.

    Checking before buying doesn't work in several situations. One is switching from Windows to Linux or from Windows to a Windows/Linux dual boot without wanting to have to buy all new hardware. Another is minors and charities, which tend to depend on donations of random hardware by those who haven't done research. A third is when after doing the research, you conclude that no manufacturers offer Linux-friendly laptop or convertible laptop/tablet PCs in a particular size range factor with a warranty in your country.

    1. Re:Beggars can't be choosers by DaHat · · Score: 0

      Provided they have the budget for a new machine in the first place.

      In which case their older machines (ie pre-windows 10) almost certainly allow disabling of secure boot. Problem solved.

      One is switching from Windows to Linux or from Windows to a Windows/Linux dual boot without wanting to have to buy all new hardware.

      Which is a tiny minority of the PC market, and of those who care, the information tends to be discoverable.

      Another is minors and charities, which tend to depend on donations of random hardware by those who haven't done research.

      In which case they tend to use them as best they can, beggars can't be choosers they say.

      A third is when after doing the research, you conclude that no manufacturers offer Linux-friendly laptop or convertible laptop/tablet PCs in a particular size range factor with a warranty in your country.

      Then you do what everyone else does when buying any product which may not fully meet their requirements... compromise.

    2. Re:Beggars can't be choosers by tepples · · Score: 1

      In which case their older machines (ie pre-windows 10) almost certainly allow disabling of secure boot. Problem solved.

      The real problem is incompatible hardware in general. I agree with you that as of the second quarter of 2017, Secure Boot is not the dominant point of incompatibility between GNU/Linux and used PCs. But as PCs designed for Windows 7 or Windows 8 continue to fail over the years, inflexible Secure Boot will be yet another hardware incompatibility that makes a suitable PC harder to come by.

      [People trying GNU/Linux for the first time on an existing PC] is a tiny minority of the PC market

      A tiny but influential minority.

      and of those who care, the information tends to be discoverable.

      "I have discovered that the PC I own is incompatible with GNU/Linux. Now what should I do to obtain the funding to purchase a compatible PC?"

      Then you do what everyone else does when buying any product which may not fully meet their requirements... compromise.

      In other words, one can reasonably conclude that Windows is better than GNU/Linux for some laptop users for two reasons. First, laptops warranted to run Windows fit more easily in bulk- or weight-restricted luggage than laptops warranted to run GNU/Linux. Second, the lower hardware purchase price gives a Windows laptop a lower total cost of ownership than a GNU/Linux laptop for any user not on a harshly metered Internet connection.

  15. An aside, on slashdot website design by Anonymous Coward · · Score: 0

    I got a weird format for slashdot just now, assumed either it was a glitch, or they'd updated it to require javascript (it works passably without, and is pretty snappy).
    So I spun up a VM and went into this story and enabled jscript.
    It said it was allowing 77 (!) scripts to run. It took 20 or so seconds to actually finish loading. It gave me a facefull of junk clickbait.
    Is this what I'm missing but blocking JS? I'm not missing it at all.
    VM image deleted. Goodbye "modern" world, I'm better off without this.
    I recommend other people disable JS and see how it suddenly looks and feels.
    (I wonder how long before whipslash deletes this post).

    1. Re:An aside, on slashdot website design by Anonymous Coward · · Score: 0

      I use RequestPolicy to block access to third party servers. The only one I have allowed is fsdn.com and I haven't experienced any weirdness.

  16. Forget that. by Anonymous Coward · · Score: 0

    Time to consider The Hurd.

    1. Re:Forget that. by sl3xd · · Score: 1

      Considered. I'll pass.

      --
      -- Sometimes you have to turn the lights off in order to see.
  17. How can an individual make it worth their while? by tepples · · Score: 1

    good luck finding parts from which to build a compact laptop.

    In addition many manufacturers will build you a workstation to your requirements, you just have to make it worth their while to do it.

    Looks at list of laptops sold by System76
    How would an individual go about "mak[ing] it worth their while" for System76, ZaReason, ThinkPenguin, and other Linux laptop makers to make a laptop smaller than 13 inches?

    Looks at pricing of base configuration of said System76 laptops
    What goes into a Linux laptop to make it cost as much as two or three entry-level Windows laptops?

  18. UEFI sucks ass by Anonymous Coward · · Score: 0

    It's a cancer. It's not worth the effort of using. If you buy a new system, most people will immediately disable it for some things to work properly. Virtualization isn't enabled by default, meaning, running VMs won't work unless you have the know-how to edit the configuration. It's stupid and ultimately useless.