So here is
New features and stuffs were added, bugs were squashed, blah blah blah
If you wanna know the details, go to their wiki at https://wiki.postgresql.org/wi..."
Link to Original Source
Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!
the humble pallet is arguably "the single most important object in the global economy."
The word arguably is "the lazy writer’s synonym for 'not.' For example: 'The Red Sox are arguably the strongest team in the American League East.'" --- Alex Beam
CLIPPY: I see you're writing a letter. Would you like help? Please enter a valid credit card number.
So the "news" is that there is no news?
Oh, this was another NetworkWorld post by alphadogg.
Just another InfoWorld post by the user snydeq.
David Heinemeier Hansson was sick of PHP, found Ruby, and invented Rails in 2004. No mention is made of him toying with Python. I think that if he had found Python that he would have liked it just as much. Django had not come out though.
I guess that he did the best he could with what he had, but I wonder if he would he would have just switched from PHP to Django had he started five years later.
Just read Getting Real . I was thinking of recommending their second book, ReWork, but it's mostly a rework of the first. You either get Getting Real or you don't, and if you don't get it, you have problem about getting real.
Wow that was a hard headline to parse! "What's a start-up assembly bank, and why is it on paid, open-source development?"
I'm so glad technology has come to the point where I can stop reading science fiction novels for entertainment and just pick up a newspaper.
"There are some ideas so preposterous that only an intellectual could believe them."
--- George Orwell
Don't roll your own password system. If you're a public site, use OAuth Connect to let them sign in with their account from Google, Yahoo, or some other company that specializes in this sort of thing. If it's a business-to-business site, use Kerberos or LDAP to let them sign them in with their own company's username and password. This also cuts down on the number of usernames and passwords users must remember.
And then there's the launchd / inetd way of launching services that systemd also copies. The service config file can list a set of sockets that the service binds in order to service requests. For example Apache binds to port 80 and 443. So long as all services (including mounting filesystems...) describe *all* of their external interfaces, dependencies no longer matter at all.
The init system can bind all of the sockets that every service needs all at once, and either start the real service the first time the socket is used, or start them all at once. If one service connects to another, the first request will block until the other service is ready to handle it. Then all you have to worry about is the potential for deadlocking, which you'd have to consider anyway.
Thank you for the explanation. That sounds much more elegant.
Thank you! That was very helpful, especially why you might want a script for each daemon instead of a single config file.
I like the UNIX philosophy and don't think it goes out of style just because it's a few decades old.
I am against systemd, for now, mainly because of the binary log files and how it was railroaded through the community.
However, do these programs follow the do-one-thing-and-do-it-well principle: web servers like Apache, database servers like PostgreSQL, the X Window system, the GIMP, OpenOffice? Is an init system more like one of these or more like sed and awk? That's not a rhetorical question. I'm a web programmer who loves Linux, but the kernal and start-up are still black magic to me.
Maybe an init system can be simple. I don't understand why even shell scripts are needed. Seems like they should be the exception, not the rule. Seems like configuration should be a single file that lists the programs to start from top to bottom. If you wanted add some parallel start-ups, it seems like you could just make the config file format a little fancier, maybe with some braces or indentation to express dependency.
Maybe instead of systemd we could come up with a start-up standard, sort of like the POSIX standard. Most programs seem already to be callable with the same arguments: start to start it, stop to stop it, restart to restart it. So the simple config file would call one or the other depending on which cycle we're in. Why the need for shell scripts? I've looked at them, and they mostly seem to be doing this anyway: call start on the shell script, and it calls start on the program. I see some checking, some setting of environmental variables maybe, but is this really needed? Can't programs be formalized to follow some init API? If the start, stop, and restart are not enough, maybe also an option, like --bg, that they'd all take, so the init system always calls $program --bg start, or $program --bg stop, or whatever; so that all we need is that simple config file. Those programs that don't yet follow the init API could keep using a shell script until they do.
Please have mercy if this question is terribly naive. I've tried googling . . . a little. I was hoping a real live human being could either explain it all. Or feel free to reply with some links that explain why SysV init needs all those shell scripts and can't be just a simple list or somewhat-simple declarative configuration.
The article seems to contradict itself:
While perpetual motion machines would violate known physical phenomena—like the conservation of energy—cold fusion is possible in principle.
Oh, so it's possible!
The combination of the energy barrier of normal matter, the Coulomb barrier of individual nuclei, the negligibly low probability of quantum tunneling at all but the shortest distances, and the fact that the physics of nuclear reactions is so incredibly well-understood (and verified) all tells us that low-energy cold fusion should be impossible.
Oh, so it's impossible. But even here, don't you mean it's just unlikely?
Even though I’m a theoretical physicist myself, I’m open to the possibility that physics has it wrong, and that cold fusion could be possible
Wait, you said it was possible in principle. Now you're saying that cold fusion contradicts theory.
The best book on programming for the layman is "Alice in Wonderland"; but that's because it's the best book on anything for the layman.