UEFI Secure Boot Booted From Debian 9 'Stretch' (theregister.co.uk) 168
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.
RedHat (Score:5, 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.
Re:RedHat (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.
Re:RedHat (Score:5, 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.
Re: (Score:2)
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 shoe
Re: (Score:2)
You will care when most oems start shipping their systems with secureboot forced on.
Re: (Score:3)
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!
Re: (Score:2, Informative)
The fact that you ignore NVMe SSDs makes you sound even more clueless...
Re: (Score:3)
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" (no
Re: (Score:2)
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.
Re: (Score:2)
Progresses towards what exactly?
Re: (Score:2)
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?
Re: (Score:2)
Progress might look different if you had software freedom.
Re: (Score:2)
Come on, those fallacies are getting old now.
Re: (Score:1)
Ah, so you just want to sacrifice package quality and QA, while adopting dependency hell, all for "business integration?" That makes sense.
Re:RedHat (Score:4, Informative)
Begone, Troll!
RedHat/CentOS haven't suffered from dependency hell for years. The adoption of YUM solved the issues.
Re: (Score:2)
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.
Re: (Score:2)
I see absolutely no benefit to UEFI. What does it have to do at all with "business integration"?
Re: RedHat (Score:4, 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.
Re: RedHat (Score:4, Informative)
PC hardware support is still years ahead on Linux, especially for stuff such as WiFi adapters and GPU.
Re: (Score:2)
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.
Re: (Score:2)
Considered. I'll pass.
Re: RedHat (Score:5, 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.
Re: (Score:2)
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-respons
Re: (Score:2)
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.
Re: (Score:2)
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".
Re: (Score:2)
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).
Re: (Score:2)
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.
Re: (Score:2)
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 i
Re: (Score:2)
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?
Re: (Score:2)
Re: (Score:3, 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 app
Re: (Score:2)
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
What about Non-Secure Boot UEFI Boot? (Score:5, 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,
Re: (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 b
Re: (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?
Re:What about Non-Secure Boot UEFI Boot? (Score:5, 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.
Re: (Score:3)
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.
Re: (Score:2)
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
"Secure boot" only ever had one mission (Score:5, 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?
and amd / intel / supermicro have the server marke (Score:2)
and amd / intel / supermicro / others have the server market that is very non windows to deal with as well.
I take issue with the definition (Score:1)
I wish we would stop using the word Security when we really mean Vendor Lock-in.
Re: (Score:2)
From that vendor's point of view, that is security. Financial security.
Re: (Score:3)
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.
Re: I take issue with the definition (Score:2)
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 unbootab
"Heir-to-BIOS?" (Score:4, 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.
Re:"Heir-to-BIOS?" (Score:5, Interesting)
Why is secure boot a 'terrible technology'? We use it quite successfully here. What are the problems with it?
Re: (Score:2, Insightful)
1. It is not "secure" at all
2. It is DRM, i.e. makes it less "your" hardware
Re:"Heir-to-BIOS?" (Score:5, 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.
Re: (Score:2, 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.
Re: (Score:3)
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.
How can an individual make it worth their while? (Score:2)
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 [system76.com]
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?
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
I find the ranting of homeless psychotics also hard to understand. That still doesn't make them right.
Re: (Score:2)
And your point is? Do you have a problem with anybody but you actually having skills and insights?
Re: (Score:2)
Re: "Heir-to-BIOS?" (Score:4, 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).
Re: (Score:2)
The answer of a truly clueless moron. What are you, 12 years old?
Re: (Score:2)
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.
Re: (Score:2)
Why do you use it? To what end?
Re:"Heir-to-BIOS?" (Score:5, 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).
Re: (Score:2)
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.
Re: (Score:3)
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?
Re: (Score:2)
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.
Re:"Heir-to-BIOS?" (Score:4, 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.
Re: (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 obtai
Re: (Score:2)
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.
Re: (Score:3)
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.
Re: (Score:2)
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.
Get the f*ck over systemd (Score:1)
Can't believe adults rant so much, so often about systemd. Get over it, for goodness sake...
Re: (Score:1)
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.
Re: (Score:2)
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
Re: (Score:2)
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, an
Re: (Score:2)
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 sys
Re: (Score:2)
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 t
No loss (Score:2)
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 rewriteab
Re: (Score:2)
It is amazing how often you can repeat the same nonsense without ever offering a single shred of evidence.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
Fascinating. You should seek professional help, there is something seriously broken in your mind.
Re: (Score:2)
If that is what you read from my comment, then you are definitely not a smart person, because that is not what I said.
Re: (Score:2)
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.
Secure Boot has No Lawful Purpose (Score:1)
Secure Boot has no lawful purpose, at all. It is designed only to prevent you using your device how you want.
Re: (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.
Re: (Score:1)
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.
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*"
Re: (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.
Re: (Score:2)
Why not educate me then?
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.
Believe it or not, people can disagree without being a shill.
Beggars can't be choosers (Score:3)
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/tabl
Re: (Score:2)
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
Re: (Score:1)
They usually are more careful about who they buy hardware from.
Re: What's the point? (Score:2)
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
Re: (Score:1)
Of course. And the reason for the PATRIOT Act is it's patriotic.
Re: (Score:2)
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.
Re: (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 [devuan.org] before Stretch is released, maybe they'll get a clue quicker.
Re: (Score:2)
They did. It's called the Devuan fork. I've been using it on some multimedia PCs at home and so far so good.
Re: (Score:2)
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
Re: (Score:2)
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?
Re: (Score:2)
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.