Forgot your password?
Close
typodupeerror
Linux

Someone Forked systemd Over Its New Birth Date Field (linuxiac.com) 169

Posted by EditorDavid from the init-to-win-it dept.
The blog Linuxiac reports: A new systemd fork has appeared with a specific purpose: removing systemd's recently added support for storing a user's birth date in JSON user records.

The fork, called Liberated systemd, published its first tagged release as v261 shortly after the official systemd 261 release. In other words, the fork follows upstream systemd while reverting the change that added the new optional birthDate field.

Importantly, this is not a new init system, a wider redesign of systemd, or a general-purpose alternative to the upstream project. Its stated purpose is to remain close to upstream systemd while removing what the author describes as "surveillance enablement"... The author recommends testing the fork in a virtual machine before using it on real hardware and warns nightly builds are more likely to be unstable than named releases.

Someone Forked systemd Over Its New Birth Date Field More | Reply

Someone Forked systemd Over Its New Birth Date Field

Comments Filter:

  • You'll end up with an empty repository (Score:5, Funny)

    by Anonymous Coward on Sunday June 21, 2026 @10:03PM (#66203388)

    once you start deleting things that are not supposed to be in systemd.

    • Re:You'll end up with an empty repository (Score:5, Interesting)

      by sinkskinkshrieks ( 6952954 ) on Monday June 22, 2026 @02:57AM (#66203588)
      systemd is what happens when a young, arrogant engineer whom tech bloggers decided was a digiterti prophet inflicts the antipattern of reinventing everything and ignoring conventions and standards imposing unreasonable costs on end-users for ego purposes. But look at all of the benefits and pretend none of the downsides exist!

      • I've literally never seen praise for Poettering on the blogs. Only critisosm of him and all of his projects.

        The fact that the projects are picked up and used by distros leads me to believe that perhaps the blogs are mistaken and there's something we're all missing.

        • Re: You'll end up with an empty repository (Score:5, Insightful)

          by DarkOx ( 621550 ) on Monday June 22, 2026 @08:10AM (#66203832) Journal

          Here is the thing both parts are true.

          Systemd really does suck. It is a lot of attack surface, it makes a lot of things that would be enjoy some security or at least blast radius control thru heterogeneity systemic risks. It turns a lot of simple failures into complex nightmares that are difficult to untangle. It offers no discoverablity, if you don't know how the hip bone is connected to tailbone you are not getting there by looking around the system you'll have to read the docs.

          90+ % of what it does was already handled just fine by existing solutions. So for all of those bloggers systemd has a zero value proposition. All suck no blow.

          However....

          If you trying to run 1000s of containers at scale with piles of micro services on each, actually systemd does give you some useful things. If you are are PaaS platform and you want to support a wide variety of work loads and make them controllable thur you management portals etc, well having some similar OS level control plane for your control plane tools to plug into is kinda of big deal, because otherwise you are looking at specialized code for each OS and maybe each version of OS you want to offer support for.

          Instead we get this dynamic, one distro picks up systemD, the PaaS guys pick it up and say hey cool we will support systemD and tell the other distros get with the program or be left behind.

          So bloggers are right if you are managing handfuls of servers the old fashion way via ssh, or just admining your own workstation - SystemD SUCKS

          If you are some SiValley tech bro looking to piss away a few million VC dollars, systemD or something like it is a necessity and uniformity and adoption level is a way more important than it being any good. It is just the latest iteration of nobody ever got fired choosing IBM, exact same thinking and underlying justifications.

          • Re: (Score:2)

            by CAIMLAS ( 41445 )

            What are the discreet benefits to the "1000s of containers at scale" scenario you mention which are satisfied with systemd which could not be or were not satisfied with init?

            There was not a lack of uniformity before. In fact, it was more consistent and uniform before systemd at a system level.

            The only benefit systemd provides is integration with eg. pulse audio - another one of this shmuck's horrible projects - and desktop integration. While that is potentially useful in and of itself, it didn't need to be

        • I've literally never seen praise for Poettering on the blogs. Only critisosm of him and all of his projects.

          The fact that the projects are picked up and used by distros leads me to believe that perhaps the blogs are mistaken and there's something we're all missing.

          Monolithic system configuration = more like Windows. And we all know that Windows is the equivalent of technological success! Therefore, until Linux perfectly mimics Windows, we can have no success!

          The entire thing is built on the premise that the end goal is to make Linux as Windows-like as possible. So adding layers of bullshit and attack surfaces on top of what was once a stable and usable system makes absolutely perfect sense. If we just keep chugging along, we can make Linux an unusable mess too!

      • Re: (Score:2)

        by AmiMoJo ( 196126 )

        It's interesting that you mention unreasonable costs for end users, because most distros have adopted systemd. That suggests that you want to impose unreasonable costs on distro maintainers for your own benefit.

        • Re:You'll end up with an empty repository (Score:4)

          by OolimPhon ( 1120895 ) on Monday June 22, 2026 @05:40AM (#66203702)

          The unreasonable costs are having to learn a whole new set of admin commands that could previously have been done with a line of Bash. When things go wrong I haven't got time for any of that nonsense. systemctl? journalctl? networkctl? The list goes on.

          • Re: (Score:2)

            by AmiMoJo ( 196126 )

            Yeah, but to facilitate you continuing to use your familiar commands, the maintainers of the distro have to forego the convenience of systemd. Clearly it offers a lot to them, which is why the vast majority adopted it.

        • Most distros ultimately lead back to a few majors. Debian being the parent for Ubuntu and everything downstream. Fedora making up the rest and then SuSE.

          • Re: (Score:2)

            by AmiMoJo ( 196126 )

            And don't they all use systemd? They must have a good reason for it.

            • Re: (Score:3, Informative)

              by drinkypoo ( 153816 )

              And don't they all use systemd? They must have a good reason for it.

              Weren't you here when we discussed this when Debian adopted systemd? The change was rammed through without the normal discussion procedure, specifically for the purpose of supporting GNOME at a time when nobody gave a fuck about it any more. The idea that they have to have had a good reason because they did it is not logic-based.

              • Re: (Score:2)

                by AmiMoJo ( 196126 )

                I do remember that, but the counter argument which seemed persuasive was that the simplifications to the init system and other apps (not just GNOME) was compelling.

                • Re: (Score:2, Informative)

                  by drinkypoo ( 153816 )

                  I didn't find them to be so. The primary advantage claimed was that it eliminated init scripts. But init scripts are really easy on modern Linux because of the boilerplate, and there are still cases where you need scripts with systemd, so it didn't actually eliminate them — It only reduced their number. The other advantage claimed was that it implemented cgroups. Well, I'm using Devuan and that uses cgroups too, they are created and managed and destroyed with simple commands and you do not need any sp

                  • There was definitely some bullshit in the arguments. One was that systemd could bring up network interfaces much faster, but when you dig into it, that speed "improvement" was largely due to not running the "arping" command to check for duplicate devices already on the network.

                • Re: (Score:2)

                  by CAIMLAS ( 41445 )

                  Simplification?

                  There was no simplification. It was all markedly more complicated and interdependent. That was literally the primary selling point of systemd, aside from "faster boot times".

      • Re:You'll end up with an empty repository (Score:4, Insightful)

        by Arrogant-Bastard ( 141720 ) on Monday June 22, 2026 @10:22AM (#66204032)
        All true - but also a young arrogant engineer who completely failed to read and learn from people who have entire closets full of computing awards (including Turing Awards) for a reason.

        There are only two valid use cases for systemd: first, as an interview question. I use it as a fast and easy way of classifying candidates; anyone who thinks systemd is in any way, shape, or form a good idea may safely be dismissed from any further consideration. Second, as a security wedge: there is so much new, poorly-written code in systemd -- with more being shoveled in all the time by Poettering's submissive kneeling fanboys -- that it provides all kinds of opportunities. (I'm being snarky but also serious: read the damn code. It's absolute crap, so much so that one could argue that the number of security holes exceeds the corpus of useful code.)

    • systemd-forkd devs ending up with systemd-initd and nothing else

  • Give my my SysVInit (Score:5, Insightful)

    by jeffy210 ( 214759 ) on Sunday June 21, 2026 @10:32PM (#66203406)

    I'm still salty about the switch to SystemD in the first place. I grew up on the simplicity of Linux's three tenets:

    1. Everything is a file
    2. Everything should be kept as simple and discreet as possible
    3. Text (ASCII) based files wherever possible for configs and logs

    SystemD came along and just blew all three of those out of the water and made it look and act more like Windows with its complications. And now it's pushing non-needed items like Birthdate into the core functions.

    • You can always .... fork it.

    • Re:Give my my SysVInit (Score:5, Insightful)

      by markdavis ( 642305 ) on Sunday June 21, 2026 @10:53PM (#66203430)

      >"I grew up on the simplicity of Linux's three tenets:"

      Those are actually Unix tenets, that Linux just inherited.

      But yeah, I generally hate the idea of systemd because it is trying to be all things and in ways that make understanding and configuring things more difficult.

    • Re: (Score:2)

      by gweihir ( 88907 )

      I am not salty. I just run all my Linux systems without the systemd trash. Has saved me from having to do emergency patches several times now.

      • There is also the option to just say "FUCK THIS" and not go along with the mainstream. Not every bad idea is completely inevitable. As you've found, there are several Linux distros that completely eschew System==D and who's policy is "We won't make our OS cooperate with totalitarianism."

        I'm not sure how many people will take it to "shootout with the cops" level, but there are some folks who will simply not tolerate or cooperate with the "You must make your OS work for Big Brother" ideas. MX Linux, Graphe

    • Re:Give my my SysVInit (Score:5, Interesting)

      by Burdell ( 228580 ) on Sunday June 21, 2026 @11:39PM (#66203468)

      So systemd-the-init-system is that. Arguably having straight-forward config files rather than wildly-varying shell scripts for startup is much cleaner. For example, since systemd can handle non-daemonizing programs cleanly, it makes throwing together a script to do something much easier (no daemonization necessary, can just run, if it fails for some reason systemd can automatically restart it if configured, etc.).

      systemd-the-project is bloated in all the things they've added, but systemd-the-init-system is IMHO a good replacement for the classic SysV and older BSD rc (I'm really out of date with BSD so don't know what they do now) styles of init. I feel that "PID 1 is dumb about what's running" turned out to not be the best idea, that's why we got things like djb's daemontools and such, but trying to be init without being PID 1 has it's own issues.

      • Re: (Score:3, Interesting)

        by caseih ( 160668 )

        Further to that systemd is highly modular. Most of it does not run in PID 1. On my fedora system there are half a dozen individual systemd module packages that can be used or not as the system needs and is designed. systemd is not at all monolithic.

        All this systemd hate is pretty infantile and entitled, frankly. You're free to build Linux to not use systemd if you want. There are distros that eschew systemd and you can use them and contribute to them. And if a project embraces systemd you are free to f

      • So you can write a service file or timer file without looking at documentation? I don't understand how they took something that worked fine as a script in a directory and made it into a 20 line config file that doesn't even abide by any known standard format. I guess it resembles ini the most, which is a Windows thing.

        • The service file is just a re-invention of JCL. That in itself might not have been a bad thing, but the way it was done stinks.

          Very little thought was given to how such a program description file would be laid out and how the rest of the system would use it. Hence the mess.

          Poettering lost me when he began running programs out of /lib. WTF? And WTF is /libexec?

        • Re: (Score:2)

          by Pizza ( 87623 )

          Each 'config file' is a bog-standard "ini" file, whereas your script (which is likely *much much* longer than 20 lines and calls numerous external tools, each with their own cmdline syntax/configs etc) is freeform bash (or zsh, or csh, or heck, even a compiled binary) file.

          Meanwhile, are you seriously saying that you can write a crontab or a new sysvinit script (or [x]inetd hook, or, or, or...) without *ever* looking at _any_ documentation (or another example)? Note that "write the script" is not enough he

      • Sysvinit had /etc/inittab as a config file and it was fine most of the time. You pick a run-level and kicks off any matching items, like terminals and scripts. It used to be that you'd point it to a single script (rc.local) for your customization. In many respects that was easier than how we handle model systems. The script would run from top to bottom. Each step was one to five lines of really basic shell script. After 5 minutes your server was up and running and you wouldn't need to reboot for another yea

    • Re: (Score:2)

      by caseih ( 160668 )

      Go right ahead. This is Linux after all. You are free to build it however you want.

    • I expect SystemD was originally created because someone looked at Apple's LaunchD and decided they wanted a GPL-compatible alternative. But it certainly has metastiz... I mean, expanded a lot since then.

      • Re:Give my my SysVInit (Score:4, Informative)

        by ISayWeOnlyToBePolite ( 721679 ) on Monday June 22, 2026 @12:14AM (#66203494)

        I expect SystemD was originally created because someone looked at Apple's LaunchD and decided they wanted a GPL-compatible alternative.

        Poettering blogpost announcing systemd explains the background: https://web.archive.org/web/20... [archive.org]

        • Re:Give my my SysVInit (Score:4, Insightful)

          by robot5x ( 1035276 ) on Monday June 22, 2026 @01:05AM (#66203530)

          that was a fascinating read - I'm a bit neutral about systemd but I have to say, this guy comes off like a pompous asshole from about word 3. But definitely some earth shattering pearls of wisdom here:

          For a fast and efficient boot-up two things are crucial:

          • To start less.
          • And to start more

          Clearly on a different level.

          • Re:Give my my SysVInit (Score:4, Informative)

            by AmiMoJo ( 196126 ) on Monday June 22, 2026 @04:20AM (#66203654) Homepage Journal

            You botched copy/pasting the quite. I fixed it for you:

            To start less.
            And to start more in parallel.

            That makes complete sense and is in fact how all major operating systems optimize boot times, and how software developers often optimize performance in general. Do as little as possible, and do as much of it in parallel as possible.

            Tricky to do with init scripts because there are a lot of dependencies to manage and checks that need to be done for timing and sequencing. systemd makes it easy and I've used it extensively for building a custom OS for embedded systems where hardware init and configuration has to happen in specific sequences, but can be parallel with other parts of the OS starting.

            • That makes complete sense

              It does. One thing I noticed back in the day during the big switcheroo is that my Arch laptop (eee 900) started to boot slower when systemd came in. Maybe they fixed that now, this was a while ago but it did not live up to the hype and even its own rationale in that regard originally.

              So I'm not saying the reasons behind systemd were poor, but the implementation left something to be desired, it was quite buggy originally (it's mostly been beaten into shape), and quite a lot of it is

        • Re: (Score:3)

          by PPH ( 736903 )

          From TFA:

          And admit it, on most machines where sshd might be listening somebody connects to it only every other month or so.

          I stopped right there. How about running ssh multiple times per day? Sure, Poettering may never forward X11 over ssh from his laptop. But his complete lack of understanding of various *NIX ecosystems just demonstrates how unprepared he is to make important system architectural decisions.

          • Re: (Score:2)

            by ceoyoyo ( 59147 )

            I saw a funny cartoon today. Someone pointed to a bin full of blue balls with one red ball in it and said "most of these balls are blue." Then someone else pointed to the red ball and said "what do you mean, there's a red ball right there."

            • Re: (Score:2)

              by PPH ( 736903 )

              How can you tell how many red balls there are in the bin if you don't properly sample its contents?

              Worse yet, if you are one of the blue balls, you can only see the adjacent 12 balls. If they are all blue, you are missing a significant, albeit a minority, of the bins contents. If we dropped 8% of a system's capabilities each revision cycle, pretty soon there wouldn't be much left.

      • I expect SystemD was originally created because someone looked at Apple's LaunchD and decided they wanted a GPL-compatible alternative

        Looked at LaunchD and decided, 'This would be better if it were done in a Microsoft way."

      • I expect SystemD was originally created because someone looked at Apple's LaunchD and decided they wanted a GPL-compatible alternative. But it certainly has metastiz... I mean, expanded a lot since then.

        SystemD owes a lot more than just a tip of the hat to Apple’s launchd.

        And of course, that is sorta what Apple intended when they released it as Open Source.

        https://github.com/apple-oss-d... [github.com]

        But launchd is, by and large, much more well-mannered in Darwin than Pottering’s Creeping Elegance “version” is in Linux.

        Here’s an interesting comparison written by someone obviously fluent in both SystemD and launchd:

        https://devops.sarmento.org/en... [sarmento.org]

    • Re: (Score:3)

      by darkain ( 749283 )

      What you just described predates Linux by a couple decades.

      The word you're looking for there is "UNIX" and there are still plenty of UNIX derivatives live and well today that never touched SystemD to begin with.

      • The problem is that there are Linux religious people who only believe Linux exists. And have stopped believing or never believed in portability and standards, that thing we used to do in heterogeneous environments and amongst people who use more than Linux. (Linux is great, but other things also exist.)

        • Don't you mean
          The problem is that there are Linux religious people who believe only Linux exists.

        • Re: (Score:2)

          by Pizza ( 87623 )

          Pray tell, what "portability standards" apply to how a system boots and manages itself?

          The only thing that UNIX(tm) and POSIX mandates is that PID1 is the ultimate child-reaper, and MUST NOT DIE. Otherwise.. every CertifiedUNIX(tm) did things entirely its own, non-portable way. Yet another reason why Linux won, even before systemd.

          (Meanwhile, are you seriously asserting that you are running production workloads on a modern non-Linux UNIX? And if you are, please enlighten us as to how those UNIXen manage

          • You're technically correct. Much worse systems like Solaris SMF or AIX's SRC demonstrate an even worse way to replace Sysvinit. For example, SMF uses SQLite databases which are truly binary opaque for much of it's startup. SRC is just poorly written shitware that's full of bugs and bad choices. It's not like System==D's worst problem is that it's not standards compliant, because (as you say) there aren't a lot of great standards in this area and I'm not sure System==D could win a "worlds worst init system"

    • Re:Give my my SysVInit (Score:4, Informative)

      by TaliesinWI ( 454205 ) on Monday June 22, 2026 @12:26AM (#66203512) Journal

      Plenty to choose from:

      https://nosystemd.org/#alterna... [nosystemd.org]

      I tend to run Devuan, which is a Debian fork.

    • discrete* but yes, systemd violates UNIX philosophy while also mission creeping to takeover every function like a god antipattern,

    • Re: (Score:2)

      by tlhIngan ( 30335 )

      There's nothing in Linux that demands you use SystemD. You can choose to use SysVInit if you really want to. Indeed the only kernel requirement is something called "init" is either in /, /bin, or /usr/bin

      But the init scripts are really just faking what init was doing - watching processes and restarting them as necessary. The SysVInit scripts are a crude re-implementation of inittab.

      • There's nothing in Linux that demands you use SystemD.

        That depends on your definition of "Linux". On my Gentoo desktop [OpenRC + MATE], TigerVNC no longer works, because recent versions require Gnome and Gnome requires SystemD.

    • Now that we have cheap AI code completion, maybe we should flood the project with patches to steer the code base back towards Unix?

    • If you want simplicity you could always use a typewriter instead of a computer. That's sort of the core problem. The simpler you make things the more capability you give up in the process. Either that or you fake simplicity.

      There was nothing simple about what systemd replaced initially. It replaced:
      - An init system which couldn't function without a shitton of complex scripts extending 100+ lines just to start a program with no consistency.
      - An init system which couldn't init anything that was event based wh

      • Re: (Score:2)

        by HiThere ( 15173 )

        I have never detected even a single advantage of systemd. It didn't bother me enough tow switch distributions, but that's the best I can say for it.

      • If you want simplicity you could always use a typewriter instead of a computer. That's sort of the core problem. The simpler you make things the more capability you give up in the process. Either that or you fake simplicity.

        Spare us the strawman. Nobody is asking for a typewriter. We're asking for an init system that stays in its lane instead of becoming the Linux equivalent of svchost.exe on steroids; a single massive PID 1 that hosts more and more system functionality every release and gathers CVE's in a bumper harvest.

        There was nothing simple about what systemd replaced initially. It replaced: - An init system which couldn't function without a shitton of complex scripts extending 100+ lines just to start a program with no consistency.

        Those scripts were *shell*. You could read them, edit them, and understand them with basic Unix tools. Systemd unit files are text, sure, but they're a giant pile of poorly documented keywords, [Unit], [Servic

    • My first reaction to this headline was "Why the hell does a system startup utility need any user records at all?"

  • I'm sure it's just like a 1990s BBS (Score:4, Funny)

    by SubmergedInTech ( 7710960 ) on Sunday June 21, 2026 @10:41PM (#66203418)

    SystemD just wants to know when you're old enough to hit on. The next field to be added will be relationshipStatus.

  • Why not ... (Score:3, Informative)

    by hcs_$reboot ( 1536101 ) on Sunday June 21, 2026 @10:52PM (#66203428)
    just entering a valid 18+ random date? The real issue will arise when applications start requiring that date to be verified (and the fork won't help then, either).

    • Re:Why not ... (Score:4, Insightful)

      by markdavis ( 642305 ) on Sunday June 21, 2026 @11:07PM (#66203444)

      >"The real issue will arise when applications start requiring that date to be verified (and the fork won't help then, either)."

      Bingo.

      Except it won't be FOSS applications. It will be on-line crap. Having the field or not doesn't matter at all. It will be a whole matter of "chain of trust" again, where you don't actually own or control your own system. Linux/FOSS will not meet that requirement and will be rejected. Just like it is rejected in a small amount of DRM games than want to control your system.

      At least with the DRM crap, it is not government-related/mandated, so market pressure can be brought to bear on such companies trying to force it. Especially relevant as the Linux "market" keeps growing and starts carrying more clout.

    • Re: (Score:3)

      by allo ( 1728082 )

      Yes, it is a first step. They add a field and an API. Programs implement the API and they are fine. But when governments make the rules stricter, the system providing the API will need to jump through all kind of hoops to do a serious verification. So your program won't do the annoying stuff, but a system-level dialog will ask you for a selfie for age verification.

      You can expect things escalating for example to the system to upload the selfie to Google or another "trusted party" to get a PKI signature for a

  • Use the epoch (Score:3, Insightful)

    by bart_smit ( 663763 ) on Monday June 22, 2026 @02:36AM (#66203578)
    All users on a Linux system are Linux users and therefore Unix users. Unix was born on 1/1/1970, so this is the DOB for all users on the system. If someone could draw a moustache on Tux, I'm sure we can use that for age verification.

    • Re: (Score:2)

      by PPH ( 736903 )

      Um ... This is about the logged in user's DOB. Not the O/S.

      At any rate, the more appropriate system date for systemd to return is March 30, 2010. The date of systemd's initial release and the death of *NIX.

  • Why? (Score:2)

    by allo ( 1728082 )

    Such forks just end as abandoned projects. Better use an init system that didn't do that crap first place.

  • A fork that removes a completely optional feature that you can toggle off, is not a fork, it's just a waste of space on github repository that no one will use.

    Why would anyone ever install this instead of just not using the field when using systemd? For any distribution or software which doesn't require this it is completely ignorable and not even mandatory to use in systemd. For any distribution of software which does require this it would be incompatible.

    This software serves no purpose.

    • Pretty soon you can't disable this field in systemd.

      • Pretty soon you can't disable this field in systemd.

        There's literally nothing in the history of this project to suggest this is the case. Since day one systemd has had two and only two requirements. Systemd and systemd-journald, and the latter gives a configuration option to simply forward all logs to something else.

        Everything else beyond this you think is "required" as part of systemd is exclusively the choice of your distribution maintainer. Direct your anger at the appropriate group.

    • Correct. It's probably just a more political statement than anything else. Anyone with any sense avoids System==D because of what a problematic insecure pile of dogshit it's always been on it's own "merits". That's why there are still several Linux distros that eschew it and BSD laughed it out of consideration: not everyone is a corporate apparatchik who will accept any naziesque garbageware crapped out by obvious Microsoft actors.

  • Treat the set date like a starting point, and make it so that any time that date field is accessed, it returns a random date between what you've set and one calculated based on the average human lifespan.

    Give them some junk data to chew on.

  • Whether it is in SystemD or not, Linux maintainers should get out in front of this before something more onerous is mandated. It is not hard to store the user DOB at account setup and provide an api that returns UserAgeInYears to the requester.
    It is not unreasonable to require age verification for some apps or websites. Linux should provide a simple mechanism to do just that and nothing more. If we dont, i am sure there will be a mandate at some point to provide much more personal information than that.
    W
    • No. Sometimes you need to resist before the whole thing goes full-retard (or full-Nazi in this case). It's not time to bend over for The Man. It's time to resist. Websites can implement their own age verification using state-issued ID checks and other measures. There is no reason why someone cannot use their computer without "authentication" to The State and many reasons why forcing that would be a mistake.

      You sound like the kind of person who would support the worst episodes of history: Nazism, Communis
      • 'Websites can implement their own age verification using state-issued ID checks and other measures'

        You would prefer people to have state issued id checks ? This is exactly what we should be making unnecessary by providing an api that simply returns userAgeInYears - not an ID.

        . 'You sound like the kind of person who would support the worst episodes of history: Nazism, Communism, and all state repression. How many times have you found yourself telling people "If you have nothing to hide, then there shou

    • Your argument fails at the subject line. Age verification is neither necessary, nor is it the actual predicate cause for almost all regulations requiring it. Age verification laws are more about instituting KYC reporting and tracking you than actually verifying your age.

      Think about it. How can you verify your age and maintain your anonymity? You can't. How can jurisdictions make laws requiring you to give up your anonymity while justifying it another way? Age verification.

      There is no good reason for i

Slashdot Top Deals

Are you having fun yet?

Close