Slashdot Mirror
SystemD Gains New Networking Features
jones_supa writes A lot of development work is happening on systemd with just the recent couple of weeks seeing over 200 commits. With the most recent work that has landed, the networkd component has been improved with new features. Among the additions are IP forwarding and masquerading support (patch). This is the minimal support needed and these settings get turned on by default for container network interfaces. Also added was minimal firewall manipulation helpers for systemd's networkd. The firewall manipulation helpers (patch) are used for establishing NAT rules. This support in systemd is provided by libiptc, the library used for communicating with the Linux kernel's Netfilter and changing iptables firewall rulesets. Those wishing to follow systemd development on a daily basis and see what is actually happening under the hood, can keep tabs via the systemd Git viewer.
Christ almighty, this beast is a fucking monster. What's next, a shell and a userland?
Glad I'm heading to FreeBSD. Linux is going down the tubes.
The world's burning. Moped Jesus spotted on I50. Details at 11.
IP forwarding and masquerading in the init process?
WHAT.
THE.
FUCK!!!!
http://youtu.be/VSbNumR9Z8k
I have no idea what is the set of features they are trying to implement. Not entirely certain it's a finite set.
I remember when people made jokes about SystemD supporting networking. But SystemD wasn't joking.
It still works well enough for me, but I'm really wondering where this is all going.
Turn back now. Nothing good can come of this.
systemd seems dead set on becoming an alternative operative system.
Which wouldn't be a bad thing if it wasn't ruining perfectly good operating systems like Debian while it grows.
I've stuck with Debian for a pretty long time (since around 2000) mostly because I know how everything works. But in the last year running testing, more and more frequently I'll find that something has been yanked out and replaced by something harder to use and understand. Maybe it's finally time to switch to BSD instead.
How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
Y'know, for all it's flaws, warts, and Dice-y-ness, I think it's a good sign that the clickbait here is stuff about systemd.
Seriously - on other websites they'll drive up pageviews by posting something like "This just in: politicians you disagree with are EVIL!! EEEEEEVIIIIIL!".
What whips up the /. crowd into a frothy frenzy? :)
Systemd
Samsung is coming out with a new line of phones that run SystemD instead of Android.
I'm sticking with OpenBSD. At least with that OS, features are well thought out and not jammed into every release because "it's teh l337!"
Trolling is a art,
What the hell is happening to the Linux ecosystem?
I've been a user of it for a couple of decades now. Although it wasn't perfect, for years it provided a better environment for me than Windows or even OS X could provide.
But that's really started to change maybe within the past 5 years. The first major debacle I can think of is GNOME 3. They went out of their way to ignore everything good about GNOME 2, and instead forced all sorts of stupid ideas upon us.
Firefox is the next debacle I can think of. It's a lot like GNOME 3 in many ways. There was a good, reliable, usable browser in Firefox 3.5. Then it all went to hell in Firefox 4 and beyond.
Now we have systemd, which is obviously dumb in pretty much all respects. It just doesn't fit within the Linux ecosystem at all. That's probably why it's so disruptive.
What makes systemd worse, though, is the impact it has had on pretty much all of the major Linux distros. Pretty much all of the most usable and useful ones (sorry, Slackware, this excludes you) have switched to it, with horrible results.
The stability of my Debian testing system has gone down the shitter since they switched to systemd some time ago. I've had more problems properly booting my system in the past six months than I had in the 15 years prior to systemd getting installed.
I'm torn at this point. I'm probably going to buy a Mac and move to OS X for my personal system, while moving all of my servers over to FreeBSD as soon as I can. I'm pretty sure that I'm done with Linux at this point. I just don't think the ecosystem can be salvaged. So much good software has been ruined.
When the only tool you have is a hammer, every problem is a nail.
Noob coders who simply throw more and more code and "problems" are a perfect example. They don't know when to stop coding up solutions in search of problems.
Systemd devs are a perfect example.
I'm sure they'll get around to adding Emacs and NetHack functionality to it sooner or later...
Ask Slashdot: I want to dress up as systemd for Halloween this year. Do you have any costume tips for dressing or acting like systemd?
Systemd is truly the best thing that has ever happened to the BSD community.
Systemd alone is making Linux totally unsuitable for serious use. So what are people doing when a formerly-stable distro like Debian adopts systemd and becomes a disaster? They're moving to FreeBSD, OpenBSD, NetBSD, Dragonfly BSD and PC-BSD.
Just today we find out that DigitalOcean now supports FreeBSD. There's clearly a very bright future ahead for the BSDs.
And it's clear now that Linux is on its way out. While Linux and Linux systems will still be around for some time, of course, everyone important who made Linux great in the past is fleeing from it. We're moving to BSD, because unlike the Linux community, the BSD community does things right. Something like systemd would never be taken seriously by them.
it's the Diseased Crap Nebula of the open source universe.
Hopefully project collapses under its own badly engineered immense weight, or I'm done with GNU/Linux
I do, but you won't be able to go through doors.
Rethinking email
Just where a Goatse t-shirt.
The world's burning. Moped Jesus spotted on I50. Details at 11.
Why not merge Pottering and RMS's efforts? Make systemd GPLv3, include UEFI and a kernel in it, put emacs on top of it and viola!!! You have the entire OS!
Yes, just go to the costume shop and buy one of everything. Put them all on.
Then since you won't be able to move, you can get your friends to roll you to the party so you can sit like a lump in the corner leaving everyone too confused and astonished to actually party.
'"make menuconfig" is a lot better. No need to run that X bloatware to configure your kernel.
That, and why not make emacs a part of systemd as well? Oh, and toss gimp into the mix. Then the OS would be complete.
I asked a few months back now, about the possibility of BSD on Digital Ocean due to all of the SystemD shenanigans of late. Got an email notification today that FreeBSD droplets are now available on Digital Ocean. It will be interesting to see if other VPS/Linux providers follow suit.
CB.
Where do you get that idea? There's no IP forwarding and masquerading in the init process. That all happens in the networkd process.
/vmlinuz /boot/bzImage /sbin/systemd /usr/bin/emacs -> /sbin/systemd
You think I'm kidding... Here, in Lennart's own words:
http://0pointer.net/blog/revis...
The viola will depend on PulseAudio so you'll have to include that too.
Actually, as frightening as your summary is, what is described in that post is even more hellish.
It basically goes down the rabbit hole designing around the expectation that a desktop system *should* have a hugely varied set of distribution bits that should be mixed and matched in weird and arbitrary ways that cannot possibly be reasonably maintained. That degree of complexity is completely out of line to try to help a realistically extremely niche use case of massive multiboot.
An argument can be made for increasingly complex stacks of software being somewhat aided, but the docker approach pretty well already has that covered (though a project *really* should carefully consider if they've done something such that a huge mass of independent projects need to work in concert just-so in an unusual combination...). Docker approach already complicates updates to the point of updating the SSL library in an image to be considered an 'anti-pattern' rather than waiting for the image publisher to dish out a whole new image and rebase (I'm pretty sure because the alternative is to admit that docker greatly complicates certain types of updates). This exacerbates that difficult situation many times over for approximately zero incremental benefit...
Now if someone advocates that firefox/chrome should operate inside a unshared namespace by default to mitigate the risk of vulnerabilities in the ever-more-complex web browser code execution ecosystem, then I could get behind that. I think docker can be a convenient approach to prototyping or even production use in very select cases. This post is just an abomination that really by all rights should have people severely question how much influence he should have over a wider portion of a linux distribution.
I really wonder what Bennett Haselton thinks of this.
It seems every time I turn around there is yet another system process overwriting my iptables configuration.
SystemD is not replacing iptables, all they have done is integrate with iptables. Systemd's approach to configuring init "scripts" is superior (no really, it is) but it means that you can't just issue a straight "iptables -t nat..." command and instead have to call it via IPForwarding=yes and IPMasquerade=yes - unless of course you want to start a script with a unit file but then are you sure that iptables is up? Is the filesystem for the script up?
I don't know why I even bother reading the Slashdot comments about SystemD as they always lack critical thinking and instead prefer to cite hyperbole and FUD.
It annoys me that someone like Poettering, who only had PulseAudio come into use because of the ability distributions had to easily change core operating system components (and wouldn't have had the existing audio-subsystem been entrenched), would then proceed to develop something specifically intended to lock down its own existence and prevent its replacement by something else. It's hypocritical.
While I totally understand why he did it -- nobody wants to put a great amount of time into something only to have it superseded -- it flies in the face of open source in general, where you contribute to an evolving 'thing', and that while your specific contribution may not exist in the future, you can be happy that you took part in the evolution of the whole, and not feel the need to stamp your face on it for perpetuity.
It also sets a dangerous precedent. What's going to be locked down next, in the name of stability, or speed, or whatever else (when it's really about someone trying to 'make their mark'?) Do we lock down the file system? Only one file system for Linux, full stop? Do we lock down the network transports? The window manager? The terminal? The command-line applications?
Then what? Do we then create a global committee, made up of people who maintain the existing components (of course), to make decisions about those components and whatever's left into the future?
I mean, yes, I agree in that case something else will surely (and quickly) rise in Linux's place (I mean, who wants to put in the time to help projects who only exist to serve their creator's vanity) but it seems a shame that Linux should end this way.
Seriously, Redhat, you need to reel your fucking "developer" in.
Divert him to other projects. Fire him. Whatever. But this bullshit needs to stop, and stop NOW.
What the fuck? systemd contains a networkd now? What about NetworkManager (another steaming pile of shit)?
systemd was proposed as a sysvinit replacement. Since then it has gained so much functionality, most of it has not been properly designed nor tested. Nor warranted. Where's the use case for embedding a fucking operating system inside the init system? Who actually wants this shit? And so many changes, for exactly zero net benefit. systemctl has auto completion? Who gives a FUCK when it also shows all of my hardware "units" in the same mother fucking list? Seriously?
Why the FUCK would an init system need a dhcp client? a dns resolver? a network "d" whatever the fuck that means?
Seriously, redhat, you are killing Linux. Everyone is lapping up systemd, and it's a utter fucking disgrace from a bunch of people who should know better.
One thing that has become obvious. Many linux "developers" have throbbing hard ons for their apple hardware and software. They *think* Mac OS X is the be all and end all of unix operating systems.
While stroking their throbbing cocks, they code up shit like gnome 3, systemd, pulseaudio, sssd, and network manager. These fuckers obviously don't use Linux for anything other than a development target, because they clearly don't rely on any linux system to do actual work. For that, they rely on their Apple hardware running the oh-so-lovely OS X. Even sssd is a stupidly designed monolithic piece of puss that has no place on Linux. Nice idea, sure, but nss-pam-ldapd already beat you there, and do it better, and more lightweight.
Really, I'd love to visit fuckers like lennart and kay and see just what the fuck these arse holes use for day to day computing. It's cant be linux, It's not useable for day to day computing tasks - other than to destroy^H^H^H^H^H^H develop Linux.
No, I'm not a anti systemd troll. I am well aware of many problems with Linux. Honestly, Redhat should employ me, pay me the big bucks, and we will turn this shit around. I knew sysvinit was lacking in the 1990s. Sound was lacking with Linux OSS and ALSA to an extend. Networking was pretty good, but could be improved.
- A 19 year veteran of Linux who is dismayed at where linux is heading
captcha: ordinary
That's the kind of clickbait subjects/headlines Slashdot needs to start using in addition to clickbait topics...
"You won't believe these five new functions systemd performs!"
That's the kind of clickbait subjects/headlines Slashdot needs to start using in addition to clickbait topics...
"You won't believe these five new functions systemd performs!"
Sorry, I forgot that listicles usually use digits, so I guess that'd be "You won't believe these 5 new functions systemd performs!".
Why do you think this stuff is happening in the init process?
Because... because... the haters on the interwebs said bleepity-bleep! And haters never lie.
TFA is clickbait, you're not supposed to actually read that crap. Where the hell do you think you are? You're going to get eaten by a grue-se.
You might want to read this post from a few years ago when the GNOME and GTK 3.x were replacing thir 2.x branches. Of particular interest is the quotes of Allan Day (GNOME dev and RedHat employee):
So not only is this about enforcing a monoculture, the reason to enforce a monoculture is because the desktop isn't about getting work done. No, the desktop - according to GNOME - is for branding/advertizing.
*sigh*
While we're on the subject, I recommend everybody read this post by the same author. It's speculative, but it does explain a lot of what has been happening to linux over the last few years... and how it may fit into the large picture.
Ce n'est pas une signature automatique.
From the article:
"With the most recent work that has landed, the networkd component has been improved with new features. "
What are jones_supa amd samzenpus smoking?
Christ almighty, this beast is a fucking monster. What's next, a shell and a userland?
No it will expand until it can read mail.
Zawinski's Law of Software Development
“Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.”
---Saying gnome 3 is better than windows 8 not so much a compliment as it is damning with light praise.
And where's an usable 'man' page for systemd?
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
It seems Linux is to be the first OS to require two large kernels running in parallel.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
as the linux community tears itself to shreads.
"This system D thing? Sorry but this has Obama's fingerprints all over it, no way I will use that." - wow, that says more about you than anything else you wrote. I can sell you a double layer tin foil hat...
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
please be done with GNU/Linux, or go back to Linux 1.0 when life was simpler
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
perhaps you need to RTFA to stop looking like a troll
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
I've been running it for 20 years from laptops all the way up to servers. Ok, so to install stuff there's usually more manual intervention and you might - gasp! - have to use the tar command occasionally, but other than that its stable, it works, and best of all it doesn't come with the latest trendy rubbish such as systemd. Patrick tends to wait things out and see how they fly rather than including something because of the Oooo! Shiny!! mentality that other dists seem to follow.
Metastasization Continues Unchecked.
1. "What the hell is with these new commands? Great, now I have to learn a whole new way of administration cause people had to change something that was never broken."
2. "Where's all the init files? How am I supposed to configure anything? I don't have time for this..."
3. "Everything is done with service descriptors? Okay..."
4. "So wait, I no longer have to write massive shell scripts that manage the entire process lifecycle, or scour google in the hope that someone else has already written said script so I don't have to?"
5. "Wow, I never realized how much I hated dealing with init scripts until I didn't have to anymore. This is SO much cleaner!"
6. "Whoa, I can monitor and control entire *heirarchies* of dependant services from one command? That's pretty damn slick..."
I still don't completely understand systemd, but now that I'm getting a handle on it, I find it conceptually and functionally cleaner, and more rigorous than the old init system. The downsides are that it's new and therefore has a learning curve, and that it blackboxes the actual service controller which is going to piss off anyone with an ounce of control-freakery in them.
Well he does, but just not quite enough right now to cause a massive fuss. He has already stated that the kdbus patches that the systemd people think will fly under the radar will have to be tested in distribution kernels first.
If you think that reading text is longer, it's because you're doing it wrong. You can open text files in binary mode and bypass the whole cr/lf and readline() overhead. In fact, if the file is corrupt, you have no choice except to open it in binary mode. The scanning for a key will be the same in either case.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
First, again, Im not talking about dosshell. I'm referring to the preemptive version of dos that had a limited release years before that, and was promptly buried - so yes, you NEED to follow the link instead of basing it on wrong assumptions. You do NOT "know this stuff cold." I was surprised myself - learn something new every day. And yes, I lived it at that time as well as for a decade before that. So tear it up if you can.
And no, tsrs don't work via timeslicing. They work by an interrupt taking control of program flow to, for example, print a line, then restoring the normal program flow. That is not time-slicing, which is using a task scheduler to divvy up slices of time driven by the timer interrupt. I wrote tsrs as practical jokes. There was no timer tick involved.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
I'm holding out for Angry Birds on systemd before I migrate to it.
Chewbacon
The Bible is like Wikipedia: written by a bunch of people and verifiable by questionable sources.
Released? It was never released to the general public. That's a beta test at most. Calling it released is like saying "MS released an OS written completely in .NET" (singularity) and they never have released it to the public. On the print spooler specifically (which is why I noted it), it is multitasking (and yes I've written TSR programs and know about interrupts). "The Print Spooler -- a move towards multi-tasking: Rather than have to wait for a print job to finish before going on to the next job, A "Terminate and Stay Resident" TSR program was written to operate with DOS. This Spooler program is begun when printing is to be done. The print buffer is filled and the the printer is checked to see if it can accept input. If it can, the computer sends the first character to be printed. If the printer isn't ready, the spooler quits but stays in RAM waiting for an interrupt that says that the printer is ready. It sends another character and waits for the next printer ready interrupt. While waiting for the interrupt, the computer is free to execute other programs just as if the spooler weren't there.
It continues the process of sending characters and waiting unitl the print buffer is empty and the spooler can terminate. The spooler then releases the buffer area and quits completely, leaving RAM. The bottom line is that the two jobs, printing and whatever else the computer is doing appear to be running simultaniously. Actually, they are just taking turns but the process is so fast that we don't notice the turn taking." and that is multitasking, regardless of you saying cooperative multitasking isn't real multitasking. Why would they call it multitasking if it wasn't? They would've called it task switching (would be more accurate) but they didn't. My use of timeslicing was accurate. Interrupt controlled is still shifting cpu time from one process, with another ceding that time.
Wrong, the way to deal with the increasing complexity due to real progress and innovation is NOT to make something with *needless complexity*
You have no engineering sense, typical of a sysD-tard
The disk buffer never reads just 2 or 4 bytes, so the poster is wrong. You can read text files in binary mode and skip all the code that reads "one line at a time". As for the purported advantage of keeping a large chunk of data in ram all the time, that's not an "advantage".
Additionally, when the registry gets corrupted, it's usually too late to"restore." I had to load it into linux and use a hex editor to remove the crap. An ini file would be simplicity itself.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
Wrong - read this post and then do some research and you'll find that several manufacturers sold computers with it.
A tsr is no more multitasking than a bios service call. Would you say that old 8086 was multitasking because it could read the keyboard only when you pressed a key, or a serial port being read only when it generated an interrupt? Nonsense. Those are simple background services that, once installed, the system has no way of controlling when they are called.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
Since my embedded box switched to Fedora 20 and systemd, its boot started to fail once in a while.
If your "embedded box" gets to decide what software to install on its own you've got bigger problems than systemd.
Watch this Heartland Institute video
Please don't post stuff like that. Poettering is already whining about "death threats." Poettering is using posts like yours to prove that systemd haters are a bunch of irrational, violent, criminals.
Why not just use Microsoft? It works.
Here is the reason you should care about systemd:
From "SystemD Abomination"
Subject Vested interest in control. RedHat and SystemD
Date Mon, 17 Nov 2014 04:40:08 +0100
by beaverdownunder:
It should be obvious to anyone that RedHat has a vested interest in making the vast majority of Linux distributions dependent on technology it controls. Linux is its bread-and-butter.
It appears RedHat has realised that, through systemd, it can readily provide preferential support for its own projects, and place roadblocks up for projects it does not control, thus extending its influence broadly and quickly. By using tenuous dependencies amongst its own projects it can speed adoption even faster.
Once it has significant influence, and the maintainers of competing projects have drifted away either out of frustration or because they are starved of oxygen, RedHat knows that they can effectively take Linux closed-source by restricting access to documentation and fighting changes that are not in their own best interests.
At this point, they can market themselves as the only rational choice for corporate Linux support -- and this would be perfectly reasonable because they would have effective control of the ecosystem.
Linux (as in a full OS implementation) is an extremely complex beast and you can't just "fork it" and start your own 'distro' from scratch anymore -- you would have to leverage a small army to do it, then keep that army to maintain it. It's just not practical.
At the same time, Linux has matured to the point of attaining some measure of corporate credibility, and from RedHat's point of view, it no longer needs its 'open source' roots to remain viable. RedHat also, understandably, fears potential competition.
Through systemd and subsequent takeovers of other ecosystem components, RedHat can leverage its own position while stifling potential competition -- this is a best-case scenario for any corporation. It will have an advantage in the marketplace, potential customers will recognise that advantage, and buy its products and support contracts.
I hope you can understand why many see this as an extremely compelling case. Arguing that RedHat has 'ethics' and would 'never do such a thing' is immature and silly -- RedHat is a corporation, it exists to profit from its opportunities, just like any other company. To attempt to argue that it would not do so is contrary to what we can assume is its default state.
It's no 'conspiracy theory' to assume that a corporation will behave like a corporation; arguing that it is just makes one look like a naive child. systemd is one large step toward RedHat gaining the ability to reap what it has sewn -- for its benefit and not necessarily ours.
Post below explains it well:
From "SystemD Abomination"
Subject Vested interest in control. RedHat and SystemD
Date Mon, 17 Nov 2014 04:40:08 +0100
by beaverdownunder:
It should be obvious to anyone that RedHat has a vested interest in making the vast majority of Linux distributions dependent on technology it controls. Linux is its bread-and-butter.
It appears RedHat has realised that, through systemd, it can readily provide preferential support for its own projects, and place roadblocks up for projects it does not control, thus extending its influence broadly and quickly. By using tenuous dependencies amongst its own projects it can speed adoption even faster.
Once it has significant influence, and the maintainers of competing projects have drifted away either out of frustration or because they are starved of oxygen, RedHat knows that they can effectively take Linux closed-source by restricting access to documentation and fighting changes that are not in their own best interests.
At this point, they can market themselves as the only rational choice for corporate Linux support -- and this would be perfectly reasonable because they would have effective control of the ecosystem.
Linux (as in a full OS implementation) is an extremely complex beast and you can't just "fork it" and start your own 'distro' from scratch anymore -- you would have to leverage a small army to do it, then keep that army to maintain it. It's just not practical.
At the same time, Linux has matured to the point of attaining some measure of corporate credibility, and from RedHat's point of view, it no longer needs its 'open source' roots to remain viable. RedHat also, understandably, fears potential competition.
Through systemd and subsequent takeovers of other ecosystem components, RedHat can leverage its own position while stifling potential competition -- this is a best-case scenario for any corporation. It will have an advantage in the marketplace, potential customers will recognise that advantage, and buy its products and support contracts.
I hope you can understand why many see this as an extremely compelling case. Arguing that RedHat has 'ethics' and would 'never do such a thing' is immature and silly -- RedHat is a corporation, it exists to profit from its opportunities, just like any other company. To attempt to argue that it would not do so is contrary to what we can assume is its default state.
It's no 'conspiracy theory' to assume that a corporation will behave like a corporation; arguing that it is just makes one look like a naive child. systemd is one large step toward RedHat gaining the ability to reap what it has sewn -- for its benefit and not necessarily ours.
Binary reads/writes are faster than text read/writes only because of the library calls made. There is NO reason (except programmer laziness and incompetence) to use the text read/write functions, which are not only inefficient but also prone to buffer flows. Opening a text file in binary mode is just as fast as opening a binary file, same as saving.
As for reading the registry being faster because it's in memory, that's easy to disprove. Open up the registry editor and search for a key. It takes a perceptible amount of time, as opposed to reading an entire 8k ini file into a buffer, which takes, at most, 8ms. And because it's so small and you're only looking for a limited subset of keys and values, you can search it VERY fast.
As for "having it all in one place", I prefer to have the program and any associated files in one place, so that it's easy to backup and restore, as well as transfer to another machine just by copying the director(y|ies). So do most people, given a choice.
Also, computers today do NOT ship with a windows install media - just a way to back up the setup files to a usb key. Heck, many computers don't even ship with an optical drive any more - they're going the way of the floppy.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
His point's correct. Text reads are slower than binary ones since the data contained, when equal, is smaller to store or read and the structure of text files is more complex, taking more time still.
Not necessarily. Your system NEVER reads or writes less than a certain block size. It takes the same amount of time to read 1 byte as it does to read the entire block.
Also, storing a simple boolean a value as either 0x00 or 0x01 takes the same amount of bytes (1) as storing it as '0' or '1'.
String values require the same amount of space (esp. if you don't bother with the whole cr/lf windows-centric 'text file mode' and just use one of 0x0a or 0x0d as the record/line delimiter.
It's quicker to read and parse a 1k file from disk than it is to search a large binary blob in ram. Try it some time.
Recovery tools are available on Windows install media for any issues (corruption).
Not any more. Today's computers do not ship with install media, and nowadays many laptops don't even have an optical reader.
The registry is stupid. It makes transfer of applications from one machine to another harder to the point of non-transportability, harder to fix when something goes off the rails, harder to customize with simple tools, and harder to use alternate values (for example, by specifying different ini files on the command line).
When people claim that text reads are slower than binary reads, they show their ignorance in several ways. (1) you do not have to use cr/lf as the delimiter, (2) NEVER use the string or line reading functions. They're for lazy people who don't know how to allocate proper-sized buffers, they have a huge amount of overhead, and they're prone to over- and under-runs, and (3) the structure of an ini file is much simpler than the hive, and if you're not happy with it, you can create your own file structure. You're not locked into any one system.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
Open/Read-Write/Close file I-O cycle for disk scattered .ini files
If your hard disk has a seek time of 8ms, then you will take, on average 4ms to read the file (ini files are usually small enough that reading one 4k block is sufficient). The time to parse it out is pretty much zero if you're doing it right. So the speed argument for using the registry isn't of any value. You won't even notice.
The recovery tools being on a separate partition does NOT help when you lose the drive, which, in my experience, is the only reason to do a system restore/reinstall (gone through about 24 drives over the years at home, plus a bunch at work). Having to reinstall both the os and go through the install routine for each program is a lot more tedious than just copying a directory with the app, data, and ini file. So on this, the registry totally loses.
So the registry doesn't help with backing up and restoring programs - it's a hindrance.
the fact text reads slower than binary storage (due to a larger and more complex structure in text)
Wow, just wow. You obviously haven't done much (if any) low-level programming. There is NO reason to open any file in "text mode" (which is a Windows quirk), which is slower and makes the file less transportable to other platforms. And the structure of an ini file is very simple. And if you don't like it, you're free to implement your own. Just load the whole file into a buffer in binary mode. You can even do it as a fixed-record-length store, in alphabetical order, and use bsearch() . My tests doing this show that you can do 100,000 key searches in a 1 meg buffer per second on a single-core cpu. I doubt anyone's going to have a 1 meg ini file, or 100,000 keys in it.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
And as I've pointed out elsewhere, using c's binary calls to read/write the ini file int ram as one big chunk instead of using the Windows calls or the calls that read or write text data are extremely fast. In fact, you wouldn't be able to time them for a 4k or 8k ini file. So the actual binary search through an 8k chunk of ram for a dozen values is going to be a LOT quicker than searching through the hive, even indexed.
Searching through a huge chunk of indexed memory is still going to be slower than searching through a smaller chunk of memory - there's no way of getting around it. It takes time to go through the index, then look up the associated value. Multiply by each key, and you don't save any time. Test it yourself - load the registry into regedt32 and search for a key. It takes a lot more than 5-8ms.
Now, onto another problem I left out - the NTFS system can restore your file system structure - but whether your files survive is a crapshoot. It depends on the mode the drive is in, and the default is to cache data, not write it through immediately. So the stuff that you've currently working on will probably get corrupted.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
Even a meg of cache is "good enuff". Also, you're an obvious troll because I've already said many times that you can read all the file in one binary read, and write it with one binary write, and if you maintain it in alphabetical order and fixed-size records (and why wouldn't you), use bsearch(), which is faster than using an index on an identical-sized file.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
Bull crap. The data structure is much simpler, as well as way smaller, with ini files, opening any file in binary mode and slurping the data is extremely fast, and if your hd isn't badly fragmented, it's probably sitting on the same track as your app, so no head movement, and you only need 1 ini file per app.
You don't know what you're talking about, troll. The real world is different from what you read somewhere. You will not notice any delay in modern hardware opening up, reading into a buffer, then closing an ini file in binary mode.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
Where do you get this "more complex file structure" lie from, troll?
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
To be honest, I appreciate what GNOME set out to accomplish with v3. One of the great things about Linux is we have options for everything (well, soon, everything except the init manager...fuck systemd). So you can choose what window manager you want to use. But why compete for the same user base?
You already have KDE going for the power user who wants complete customization of every little scrap of screen space. And if you want something lightweight there's XFCE. What Linux was lacking is a simple, clean, and consistent interface. What people like about Windows or OSX is that it's all the same. You can sit down at any windows PC (except 8, but we know what a disaster that is) and be able to find your way around if you've ever used another windows PC. If you're trying to actually manifest the Year of the Linux Desktop, you kind of need something like that. And that's what GNOME 3 is. They take away customization to focus on doing the fewer things that they do well and cleanly.
I got both my grandfather and my wife's grandmother on Linux after they got sick of the viruses and malware on Windows. For them I installed Mint with Cinnamon, which is based on GNOME 3. My grandfather is not completely computer literate. My wife's grandmother is a disaster. Both of them were able to navigate their way through Cinnamon just fine. They've been using it for going on 4 months now and I've had exactly 2 tech support calls. GNOME 3 and its derivatives are great for non-savvy users like them, and I thank the devs for delivering a product like that.
Now, I'm in the "optimize every pixel" crowd, so I run KDE. But I'm glad GNOME 3 exists because they serve a different need, and there's room for both.
Systemd on the other hand, is a damn virus that is taking everything over and shoving worthwhile alternatives out. It can burn in hell.
We don't have a state-run media we have a media-run state.
Text files have added overheads internally in their structure
Equal data in text is larger and slower
Absolutely not true. Name one overhead. The only one I can think of is the old DOS cr/lf instead of using either 0xa0 or 0xd0, which is not needed.
Storing a boolean true or false is 1 byte in either text or binary.
Storing strings is the exact same as long as you don't use the old DOS EOL.
You either don't know what you're talking about or you're trolling - and I really don't care which, because it's obvious you've never written a program that tests the limits of what's possible (or maybe not even a program at all). Troll away or go away - I don't care which.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
The ONLY platform that uses cr/lf is Windows - and now even that's optional. Maybe you should get out in the world more. As well, the hd cache algorithms store more than 1 cluster at a time, in anticipation that the next read will probably be from somewhere close by. Hence if your disk isn't too fragmented, it's already in cache, and maybe even in the OS's cache (if you're using a modern OS), so no head movement whatsoever. You really need to get with the times.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
If I have a choice between believing someone who needs to quote Microsoft because they haven't put it to the test, or the results of actual testing, guess which I'm going with :-)
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
This isn't new. People were using 3rd-party read-caching (and write-caching) software more than 20 years ago.
Also, even Microsoft's latest iteration (Windows 8.1) uses ini files for things like the setting for a user's desktop, which were deemed too critical to leave to the vicissitudes of the registry.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
You really don't get it. All data is binary. Even text files. The problem is that most people use "text mode" to read and write to text files, which is slow as all hell. There is no reason, even under Windows, not to read and write text data using the same system calls, which gives the same speed. Stackoverflow got this one really wrong. Test it, and you'll see. Oh wait - you can't because you're not a real programmer.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
Software caches do not use FIFO algorithms to expire data. You really shouldn't expose your ignorance.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
I already addressed the other points, and NOBODY uses a FIFO as a disk cache. Also, "Cache access overhead is constant time regardless of the size of the cache" is false.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
AC wrote: "Just imagine a Beowulf cluster of these :)"
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.