We are splitting hairs here probably. After reading the article it looks like the author wrote it as a look back on their relationship with bazzite. A more descriptive one could be “bazzite and me - a post mortem” or something. It doesn’t come across as a bad faith title, at least to me
(1) "Judge" is not necessarily identical with "due process." (2) Congress can't override constitutional protections by passing new laws. That would require a constitutional amendment.
A law cannot overturn the Constitution, you need an Amendment for that. In principle, anyway. If you have a Supreme Court that abdicates its duties then you can do whatever you want, at the cost of legitimacy.
The nuances of criminal procedure may not apply, but the fundamental constitutional rights still do, as well as human rights. Indeterminate detention violates both.
A distinction without a difference, and it's questionable whether deportation is actually the goal here. If that were the case they could put him on plane today.
Basically, the guy admits that he overstayed the terms of the Visa Waiver Program, but is arguing that the fact INS started processing his adjustment of status application gives him the right to stay in the U.S. until it's resolved:
> Culleton concedes he is removable under the VWP. Reply 10. But he argues that because USCIS accepted and began processing his adjustment of status application, he is entitled to due process protections in its fair adjudication. Id. at 9. The Fifth Circuit has foreclosed this very argument, reasoning that the VWP waiver includes a waiver of due process rights. See Mukasey, 555 F.3d at 462. And “[t]he fact that [Culleton] applied for an adjustment of status before the DHS issued its notice of removal is of no consequence.” Id.
Remember that the whole point of the Visa Waiver Program is that you're conceding up front that you're just visiting and aren't making a claim for asylum or whatever. The idea is that the U.S. makes it easy for you to enter, in return for you agreeing that the U.S. can easily deport you if you overstay.
Well to be fair, you don't need to understand how SystemD is built to know how to use it. Unit files are pretty easy to wrap your head around, it took me a while to adjust but I dig it now.
To make an analogy: another part of LFS is building a compiler toolchain. You don't need to understand GCC internals to know how to do that.
> Well to be fair, you don't need to understand how SystemD is built to know how to use it.
The attitude that you don't need to learn what is inside the magic black box is exactly the kind of thing LFS is pushing against. UNIX traditionally was a "worse is better" system, where its seen as better design to have a simple system that you can understand the internals of even if that simplicity leads to bugs. Simple systems that fit the needs of the users can evolve into complex systems that fit the needs of users. But you (arguably) can't start with a complex system that people don't use and get users.
If anyone hasn't read the full Worse Is Better article before, its your lucky day:
LFS is full of packages that fit your description of a black box. It shows you how to compile and configure packages, but I don't remember them diving into the code internals of a single one.
I understand not wanting to shift from something that is wholly explainable to something that isn't, but it's not the end of the world.
No, its not the end of the world. And I agree, LFS isn't going to be the best resource for learning how a compiler works or cron or ntp. But the init process & systemd is so core to linux. I can certainly see the argument that they should be part of the "from scratch" parts.
The problem is ultimately that by choosing one, the other gets left out. So whatever is left out just has one more nail in its coffin. With LFS being the "more or less official how-to guide of building a Linux system", therefore sysvinit is now essentially "officially" deprecated by Linux. This is what is upsetting people here.
I'm OK with that in the end because my system is a better LFS anyhow. The only part that bothers me is that the change was made with reservations, rather than him saying no and putting his foot down, insisting that sysvinit stay in regardless of Gnome/KDE. But I do understand the desire to get away from having to maintain two separate versions of the book.
Ultimately I just have to part ways with LFS for good, sadly. I'm thankful for these people teaching me how to build a Linux system. It would have been 100x harder trying to do it without them.
Linux is just a kernel, that does not ship with any sort of init system.. so I don't see how anything is being deprecated by Linux.
The LFS project is free to make any decisions that they want about what packages they're going to include in their docs. If anyone is truly that upset about this then they should volunteer their time to the project instead of commenting here about what they think the project should do IMO.
nothing is actually stopping people from understanding systemd-init except a constant poorly justified flame war. it's better documented than pretty much everything that came before it.
> As a personal note, I do not like this decision. To me LFS is about learning how a system works. Understanding the boot process is a big part of that. systemd is about 1678 "C" files plus many data files. System V is "22" C files plus about 50 short bash scripts and data files.
However the reasoning they provide makes sense.. It's hard to build a Linux system with a desktop these days without Sysd.
Maybe they're KDE users. I was under the impression that gnome requires it. FTA it sounds like KDE will soon too. Gentoo doesn't come with a desktop by default either, you have to emerge it, which might install systemd..
FTA: "The second reason for dropping System V is that packages like GNOME and soon KDE's Plasma are building in requirements that require capabilities in systemd"
> I was under the impression that gnome requires it.
It doesn't seem to require it at this moment. I have "-systemd" in my USE flags, and have neither sys-apps/systemd nor gnome-base/gnome currently installed. After enabling several USE flags that have nothing to do with systemd [0], emerge was quite happy to offer to install gnome-base/gnome and its dependencies, and absolutely did not offer to install systemd.
Honestly, I don't even know if GNOME has a hard dependency on Wayland... I see many of the dependent packages in the 'gnome-*' categories have an "X" USE flag. I CBA to investigate, though.
Is KDE Plasma building in hard systemd requirements, or is it just building in hard Wayland requirements? I'd known about the latter [1] and -because I'd thought it was important to the KDE folks that KDE runs on BSD- would be surprised if they irreversibly tethered themselves to systemd.
[1] Though do note that the same blog post that announced the change in policy for Plasma also announced that no other KDE software was going to have a hard dependency on Wayland for the foreseeable future.
Read the article: "The second reason for dropping System V is that packages like GNOME and soon KDE's Plasma are building in requirements that require capabilities in systemd"
I really like SeaFile for this kind of thing. It follows the "do one thing and do it well" philosophy. It's just file sync with some basic document editing features (markdown, .doc I think). Super fast and dependable, highly recommend.
From what I understand (may be wrong) this is exactly the reason that they stopped allowing Linux installs on PS3s.
People were buying them just for this purpose. However, the consoles were sold at a discount because Sony expected users to buy games, controllers, etc. If someone bought a PS3 alone, without anything else then Sony lost money.
I think it's beta for a reason. I just tried the appimage for their latest release and it's behaving in the same broken way that I remember.
I have a multi-monitor setup with different size & resolution screens, so that may be a factor for the problems I'm having. Really hope it'll work someday.
reply