Forgot your password?
typodupeerror

Comment: Re:UNIX Philosophy (Score 1) 528

by drinkypoo (#48202169) Attached to: Debian's Systemd Adoption Inspires Threat of Fork

My point was simply to stress, that what the early Unix developers did was a reflection of the challenges they faced at the time, and that the lessons they learned reflects that. There are no dogmatic and universal Unix rules with a permanent truth value forever and in all ways of doing computing.

Nobody said there were, but you were completely misguided. Piping is a key feature of Unix, and nobody would suggest removing it today. The key principles of Unix are not "to be obeyed" simply because they are rules that you are meant to follow. They are principles that emerged from development (like piping) which became a "way" that people follow because they make sense.

No. Maybe the log file implementation, but they didn't even get that right. An error in the file means the whole thing is useless.

Of course not. Just because a daemon died before finishing its log entry doesn't mean the log file can't be read. journalctl is quite good at dealing with such corruptions.

If moving the goalposts is the best that you can accomplish, then surely we cannot progress this conversation past this point. There are many things which can happen to a log file besides truncation.

Also, binary logs are just plain wrongheaded, period, end of story, if they are not in a format which common tools can already read.

Not a problem; all the standard Linux text tools like "grep" and "tee" work great together with journalctl through the basic concept of piping.

They don't work without journalctl. And this is relevant because text logging (which does work without journalctl) is a second-class citizen to the binary logging. This is the part of the binary logging which is completely unacceptable. If only one of the logs is going to be accurate, it must be the log which I can read without special tools. Indeed, with a filesystem debugger or even a filesystem editor, if necessary.

It is a very Unix way of dealing with such "problems".

False. You only say that because you do not understand the Unix Way, which includes preference for flat and human-readable files. You are praising one particular tree while cutting down the forest.

Not having the right tools in the box is simply a shameful thing for a paid SysAdmin.

In the real world, where things sometimes do not go according to plan, it does not make sense to tie myself to proprietary tools. This point has been proven time and again, again, in the real world. Your coulda woulda shoulda nonsense is just that; journald coulda woulda shoulda made text logging as important as binary logging, and then the chief objection to it would not even exist. But arrogance has led its development otherwise. Presumably this will be fixed and eventually, with some snarky bullshit comments about how it's for the fogeys thrown in as a means of avoiding any personal responsibility for the bad decision in the first place.

It is so trivial to read and analyze journal log files on other computers or through a boot media.

I find your lack of imagination typical, but disturbing. It is, of course, the mindset which led to systemd, so I am anything but surprised to see it here.

Comment: Ask the project community (Score 2) 54

by gmuslera (#48202153) Attached to: Ask Slashdot: Aging and Orphan Open Source Projects?

If you won't support it elsewhere, ask the community if anyone of them want to host/support it. It just requires an i.e. github account to host the code, and the key pieces of information of forums/wiki pages/etc could be move there by the community if there is enough interest.

In the end, if the project wasnt developed exclusively by your company developers, it belongs to the community too.

Comment: Re:good (Score 1) 310

by drinkypoo (#48201961) Attached to: 3D-Printed Gun Earns Man Two Years In Japanese Prison

A better example of how effective armed citizens are against the government would be Waco, but that doesn't support your point.

The particular citizens of Waco we're discussing decided not to resist when the FBI rolled in with tanks and flamethrowers. Then the FBI parked a tank on the escape hatch and set the building on fire with a flamethrower. This was mounted on another tank, clearly visible in the only decent footage of the incident, shot at long range because the FBI wouldn't permit the press anywhere near. They knew where the hatch was because they had advance information, and they had the complete plans of the facility. This led to the suffocation death of the people we're talking about. If this is an example of anything, it's an example of a time when armed defense was warranted, and an example of what will happen to you if you concentrate yourself.

Comment: Re:Solving the problem wrong (Score 1) 556

by Tablizer (#48199851) Attached to: NPR: '80s Ads Are Responsible For the Lack of Women Coders

Sometimes that works, but shops often dictate or encourage certain styles and practices that may hinder "personal productivity" practices so that the team can do maintenance.

And it's not just a matter of typing: there are screwy schedules, screwy deadlines, fickle requesters, etc. If you finish coding fast, they'll make you install software, fix Outlook, clean printers or whatnot.

Yes, it's a living, but typically one plateaus early salary-wise. Why not encourage women to be sys admins or high-end application trainers? Why focus on coding?

Comment: Re:Dongle Bells! (Score 1) 116

I remember, back in the early 80s, some friends and I pooled our allowance, bought an Atari joystick, then tried to make an adapter for the 9-pin Apple IIe joystick connector- not realizing the reason the Apple joysticks were so damn expensive was because they were analog.

"Our vision is to speed up time, eventually eliminating it." -- Alex Schure

Working...