Forgot your password?

Comment: Re:Key Point Missing (Score 2) 34

by NewYorkCountryLawyer (#47234405) Attached to: Appeals Court Finds Scanning To Be Fair Use

The summary misses a key point. Yes they scan and store the entire book, but they are _NOT_ making the entire book available to everyone. For the most part they are just making it searchable.

Agreed that it's not in the summary, but as you correctly note, it's just a "summary". Anyone who reads the underlying blog post will read this among the facts on which the court based its opinion: "The public was allowed to search by keyword. The search results showed only the page numbers for the search term and the number of times it appeared; none of the text was visible."

So those readers who RTFA will be in the know.

+ - Appeals Court finds scanning to be fair use in Authors Guild v Hathitrust

Submitted by NewYorkCountryLawyer
NewYorkCountryLawyer (912032) writes "In Authors Guild v Hathitrust, the US Court of Appeals for the Second Circuit has found that scanning whole books and making them searchable for research use is a fair use. In reaching its conclusion, the 3-judge panel reasoned, in its 34-page opinion (PDF), that the creation of a searchable, full text database is a "quintessentially transformative use", that it was "reasonably necessary" to make use of the entire works, that maintaining maintain 4 copies of the database was reasonably necessary as well, and that the research library did not impair the market for the originals. Needless to say, this ruling augurs well for Google in Authors Guild v. Google, which likewise involves full text scanning of whole books for research."

+ - Councilman/Open Source Developer submits Open Source bill->

Submitted by NewYorkCountryLawyer
NewYorkCountryLawyer (912032) writes "New York City Council Member Ben Kallos (KallosEsq), who also happens to be a Free and Open Source Software (FOSS) developer, just introduced legislation to mandate a government preference for FOSS and creating a Civic Commons website to facilitate collaborative purchasing of software. He argues that NYC could save millions of dollars with the Free and Open Source Software Preferences Act 2014, pointing out that the city currently has a $67 million Microsoft ELA. Kallos said: "It is time for government to modernize and start appreciating the same cost savings as everyone else.""
Link to Original Source

Comment: A little late, but welcome (Score 1) 136

by NewYorkCountryLawyer (#47119749) Attached to: Federal Court Pulls Plug On Porn Copyright Shakedown
A cynic might argue that the key difference in this case was that, for a change, the ISP's, and not merely defendants, were challenging the subpoenas; but of course we all know that justice is 'blind'.

An ingrate might bemoan the Court's failure to address the key underlying fallacy in the "John Doe" cases, that because someone pays the bill for an internet account that automatically makes them a copyright infringer; but who's complaining over that slight omission?

A malcontent like myself might be a little unhappy that it took the courts ten (10) years to finally come to grips with the personal jurisdiction issue, which would have been obvious to 9 out of 10 second year law students from the get go, and I personally have been pointing it out and writing about it since 2005; but at least they finally did get there.

And a philosopher might wonder how much suffering might have been spared had the courts followed the law back in 2004 when the John Doe madness started; but of course I'm a lawyer, not a philosopher. :)

Bottom line, though: this is a good thing, a very good thing. Ten (10) years late in coming, but good nonetheless. - R.B. )

Comment: Re:No... (Score 1) 533

by t_hunger (#46958845) Attached to: Ask Slashdot: Practical Alternatives To Systemd?

I cant be completely sure here, but there is a funny pattern I have noticed over the years that may explain your experience. Over and over again, I hear about problems that require these over-engineered solutions from people running over-engineered distros that I just cannot reproduce using my (cleaner) system. So I suspect somewhere in your excessively complex system you have managed to break apache in a way that I cannot reproduce using a simpler system.

Considering that reparenting processes that double fork is tried and true unix philosophy: It would be somewhat surprising to see apachectl properly clean up after itself in your so called cleaner system. Maybe you just fail to properly recreate the problems in your trimmed down universe?

And yet this is an argument for introducing yet more excessive complexity to remedy? Doesnt make sense to me.

None of the init systems currently in use is conceptually very complex. In the end sysv init is actually one of the more complex ones. The others are of course different, but I would not actually call them conceptually more complex.

In fact setting up a service and then starting it is significantly simpler with systemd (and upstart and openrc) than it is with sysv init. Give it a try before complaining about it.

Why would I care? I dont use that system and am not affected by their bugs.

Hmmm... why would you? Maybe because these are fundamental issues with how sysv init works?

Comment: Re:No... (Score 1) 533

by t_hunger (#46958715) Attached to: Ask Slashdot: Practical Alternatives To Systemd?

I think you've lost sight of the purpose of an OS and the purpose of logs. An OS is not running for the sake of running an OS, and logs are not persistent structured application data, but ad-hoc information about the behaviour of the system for human consumption.

I am not talking about structured application data, I am talking about facts that go with the actual log message like the timestamp, the PID that the message originated from, the capabilities the process has that originated the message, the full filename of the process running, which cgroup the message originated from, which boot id this message belongs to (really nice if you want to see one boot/run/shutdown cycle only), that kind of data.

Having that information in the journal is really nice. Not having to parse it out of some textfile where some application put it in a more or less randomly selected format is even nicer. Correlating data from different log files written by different applications is a huge pain that is completely gone with journald.

They need to be filtered, sliced, and flattened as needed *post-facto* to be of any use. Given that you don't even know what I want to log, from where, how is that going to be normalised in a centralized journal? Will it let me query by anything more than straight filter on app or PID etc - like I can already do?

Yeap, it does. It makes full use of all the extra data it adds to the log entries and thus allows for way more reliable and powerful filtering, slicing and dicing:-)

Comment: Re:Accept, don't fight, systemd (Score 1) 533

by t_hunger (#46958571) Attached to: Ask Slashdot: Practical Alternatives To Systemd?

I'll tell you when: when GNOME developpers took the path of making it all but impossible to have GNOME properly working with other init systems. And that's just the "I've had enough" point in time, not the one and only example.

So the GNOME project making a technical decision that makes their live easier is forcing something down your throat. You are being a bit egocentric, aren't you?

Some decision taken over the past years in various linux distributions have been taken not out of technical merit or discussion, but out of personal interests, or for political reasons. Sometimes it comes discreetly through some clever marketing that everyone swallows and when you notice it, it's already too late (systemd), sometimes through hostile takeovers (yes, Debian, I'm looking at you *cough* libav *cough*) where there is nothing you can do as a user because a few guys in power decide what is good for you.

Do you have prove for any of those claims? Where are the army of developers that do something about the decisions and flock to projects that are not falling for the propaganda? Or are you the only one that understands what is being played here?

Linux used to be about choice, but the list of these non-technically-based decisions that reduce our options is getting longer and longer recently.

This statement does not become true by repeating it.

FLOSS always had a strong "who does the work is right" approach. What the users say has always been secondary.

Whatever will happen, don't tell me that the many voices around objecting to systemd have been listened to or their objections to core-design problems addressed.

There are loud voices speaking out against systemd. Do not mistake that for many voices. In Debian the systemd oponents failed to find five people required to call for a vote to overturn the decision made by the technical committee! And that after all the fuss taht was raised during the discussion process.

systemd may very well be the best init software ever written, but then there is the manner. The way it's currently spreading its arms out of its role as an init system in a non UNIX way for political reasons, acting like a kernel above the kernel, is what most people are complaining about.

Why bother to write something that is as good as what was there before? Systemd tries to do more than init ever did, right. But much of that actually makes sense if you take the time to read up and think about it.

Just read this whole thread, yes there are trolls, but there are sensible people making reasonnable arguments. And what is the answer they're given: "you're holding it wrong".

I have seen very few reasonable argument levered against systemd in this thread. But then what can you expect from a thread that has an april fools joke listed as a fact?

I mostly see misinformed or uninformed posts. What can you tell people that form a strong opinion on something without bothering to learn about it first? "You're holding it wrong" is actually a rather polite way to put it IMHO:-)

Comment: Re:No... (Score 1) 533

by t_hunger (#46958159) Attached to: Ask Slashdot: Practical Alternatives To Systemd?

No it one of systemd's goals to manage a system reliably.

Processes that double fork end up with the init process as its parent in the process tree: That is unix-philosophy at work and apache is not to blame here.

That makes it really hard to manage things like apache without additional concepts like cgroups. Those are actually not complex nor do they require lots of code to be implemented, but they need to be managed in a central place to be useful. So systemd does that right in the init process so that you get maximum benefit from the concept.

Comment: Re:Accept, don't fight, systemd (Score 1) 533

by t_hunger (#46958043) Attached to: Ask Slashdot: Practical Alternatives To Systemd?

Most packages do not depend on systemd being PID1, they depend on other things that found a home in the systemd repository. One big thing is of course udev for things that are close to the hardware. The other big thing is user session management. Basically systemd can replace all the custom start-up-the-desktop-environment code that all the desktops implement to make sure all their services get started and keep running. Then there is logind which manages who is logged in where and who has access to which keyboard/graphics card/mouse/etc. That is pretty essential for any modern desktop environment, too.

Note that all these interesting things are interfaces that can be implemented for other init systems as well. Unfortunately nobody stepped forward to do so yet. The implementations found in systemd are tied to systemd being PID1 (more or less badly), since they e.g. use the systemd interfaces to manipulate cgroups.

Comment: Re:Accept, don't fight, systemd (Score 1) 533

by t_hunger (#46957627) Attached to: Ask Slashdot: Practical Alternatives To Systemd?

So you want to have a tiny init process that spawns a bigger init process that does all the actual work? If the "big init" fails, then your system is hosed. If your "small init" fails, then the system is also hosed. Your proposal gets more code into the critical path, not less.

But then your problem is that other projects start to depend on systemd. What exactly are you objecting to here? That Systemd finally solves real world problems that developers face when implementing their software? Or that developers go ahead and fix the issues that they were unable to fix before? In the end you claim we should keep bugs open because some people on the internet are feeling uneasy.

Yes, there are bugs in systemd, just like there are bugs in sysv init -- even after decades of use. Yes, there will be some exploit sooner or later targetting systemd, just like there will be some for every other piece of software. But that should not stop people from improving the status quo.

Lennert and some other guys wrote a bit of code and went out to talk about it. They got feedback, and improved their code based on that feedback. At some point more people started to care about the code and so they contribute. Much later some other people sit down together and agree that this piece of software addresses problems they have, so they depend on that software -- either as something providing a service to their own software or as a basis for their distribution. At which point in the story does somebody grab you and forces a USB stick down your throat?

Comment: Re:No... (Score 2) 533

by t_hunger (#46954795) Attached to: Ask Slashdot: Practical Alternatives To Systemd?

"a convenient way to kill apache with all the crap that it started,"

Something wrong with apachectl stop?

That kill apache, not the crap it started and that forked itself away.

"a more robust boot process that is not sprinkled with sleep 5 statements to give daemons enough time to be fully up before bringing up services that depend on them being there."

You're confused, you actually getting a less robust boot process here. But it will be faster!

Well, ok. My computer boots fast enough without it, thanks.

Systemd can set up filesystems without racing, something that is not possible with sysv init. No more races makes for a more robust boot. In fact systemd does address most of the race issues found in the debian init system. Go and check their bug tracker if you do not believe me.

That you were unable to configure your system to make it boot with systemd is anecdotal evidence at best. I bet it did not boot right away when you installed your first sysv-init based Linux ever either;-)

I never measured the boot up times, so I am not sure whether systemd is faster or not. I frankly do not care one way or the other.

"a more secure system by being able to isolate daemons from one another and the rest of the system."

A far less secure system actually. Without it, the only real attack front is sshd. With it, we suddenly have another front to worry about - and an attack here is likely to be much more damaging.

At least here systemd has no open ports. Why does it matter whether systemd, upstart, sysv init or openrc started the sshd under attack?

With the options to limit the process that systemd offers I can even severely limit what an attacker can do on my system once a daemon is compromised. Those countermeasures are of course also possible with init-scripts, but they are *way* harder to implement securely. I have not seen many distributions that bothered to add any additional security measures to their init scripts.

A local user is something different, true, but considering that you are referring to sshd that does not seem to be your argument.

"a lot of convenient system config tools that work on (almost) all modern Linux distributions and do so even better that the "do one thing and do it well" tools that got replaced by them"

You REALLY seem confused now. You have the players backwards.

Read a couple of man-pages and see for yourself.

Comment: Re:No... (Score 5, Insightful) 533

by t_hunger (#46954637) Attached to: Ask Slashdot: Practical Alternatives To Systemd?

the journal instead of a set of randomly formatted text-dumps all over /var/log,

I'll take the text-dumps any day, thanks. And since they're usually created via *syslog*, they may not even be stored locally. And they are easy to manipulate with the available shell tools (grep; cat; awk; etc). If you want a database-driven syslog, there are plenty around.

You can wire up syslog to the journal. Why would you want to convert rich information into a string and shove it down a pipe before you make use of it? Let's start with a useful format and use lossy conversion methods on that when needed, not the other way around.

You are not ripping your CDs to mp3s either so that you can burn other CDs by converting those mp3 files to WAVs either, do you?

a convenient way to kill apache with all the crap that it started,

It seems you're getting closer to the real problem. Apparently you don't know how to operate a vaguely modern unix system.

So please enlighten me: How do you kill apache with all the php/ruby/whatnot crap it directly or indirectly spawned? With systemd it is just one convenient systemctl stop apache

Please do not assume that I am too young or too stupid to know the good old ways. I have been around for a while, even though I still have not managed to learn not to get into discussions at slashdot that are bound to end up in namecalling.

a more robust boot process that is not sprinkled with sleep 5 statements to give daemons enough time to be fully up before bringing up services that depend on them being there.

Usually the sleeps are for hardware settling, not for script startup. Eg. when you plug a USB device that may take a couple of seconds to be available after powering on. This will be needed *regardless* of what script is running the show. And dependency management on start scripts is a solved problem. Have a look at FreeBSD/NetBSD rc.d system, or Solaris SMF.

I was more thinking about starting postgres before the server that uses that DB to store its stuff. Grep for "sleep" in the init scripts of the sysv-init distribution of your choice: You will be surprised.

a more secure system by being able to isolate daemons from one another and the rest of the system.

So, its a startup daemon AND a kernel, huh?

Check out , especially all the options starting with "Private" there.

a lot of convenient system config tools that work on (almost) all modern Linux distributions and do so even better that the "do one thing and do it well" tools that got replaced by them

Convenient for who? For you, because you cannot be bothered into using the existing tools? You may have some unusual requirements, it doesn't mean everyone else has the same needs. And while I'd applause a sort-of-standard way of bootstrapping Linux distros, adding complexity seems to be a pretty stupid approach.

Convenient for everybody. Just try the things that come with systemd. Most are a real improvement over the existing tools to manage hostname/date/time/timezone/locale/service/network/efi boot loader/virtual machine/whatnot. At the very least they are way more consistent in how they work and they work on all modern Linux distros in the same way. That was never possible before.

Yes, I know: Just suggesting to look into systemd is sacrelegious:-) Sorry, I won't do that again.

Let's just wait a year or two. By then all the hotheads that are running for the BSDs now will be back, everybody will be using systemd (including gentoo and slackware) since it clearly is the best approach available right now. When somebody finally comes along in 10 or 15 years with a good idea to replace systemd she will be yelled at for breaking away from the tried and true systemd that has been good enough for everybody this past decade.

Comment: Re:Accept, don't fight, systemd (Score 5, Interesting) 533

by t_hunger (#46954333) Attached to: Ask Slashdot: Practical Alternatives To Systemd?

The problem is: A *tiny* init process won't be able to offer the *exactly same* functionality. The functionality has to come from somewhere, it does not fall from the sky: Some code needs to implement it.

If you want to keep PID 1 tiny then you can implement the actual functionality in separate processes. You now have two or more process and now you need code in the tiny init process that makes sure the controlling processes are getting started (and restarted). Remember: Those daemons provide the actual functionality, so PID1 can not depend on that to start those daemons in the first place.

You need code that facilitates a communication channel between the processes. You need code to lock out processes that are not meant to talk to your tiny init process. You need a protocol that the init process speaks and that allows it to be remote-controlled. All of sudden that tiny process is no longer tiny and your architecture is much more complex than it would be otherwise.

That complexity requires you to add more code to mitigate communication failures, to synchronize data structures between all the different processes that need access to them, you need to be careful not to introduce race conditions between those processes. In the end you end up with a pretty big init process and a bunch of big and nearly equally critical daemons surrounding it. I do understand where the systemd guys come from: Keep the architecture simple, and put absolute minimum amount of code into PID1 to provide the functionality they want. That makes the overall system less complex and easier to reason about, which is good for security and robustness.

Read the code, it is actually pretty ok.

For large values of one, one equals two, for small values of two.