Slashdot Mirror

I decided to cut ties with any and all Mozilla products because of all Mozilla's little political and philosophical dramas.
Flag as Inappropriate

But, that's what they want you to do, that's how the subversive forces operate. Mozilla was compromised. If you don't fight for the things you love, your enemies will destroy them.

I suggest you read some open source software history. The Stasi subversion tactics talked about in the above video link are being used against open source software as evidenced by leaked emails in the second link.

Zawinski's Law

My New Jersey driver's license still has me named CHRISTOPHE because back in 1993 or so when I got my license -- go ahead, count the number of characters. Ten. The idiot programmers who put together New Jersey's database allocated TEN CHARACTERS for the first name. Fucking morons. First of all, it's standard procedure, when inventing a completely arbitrary length limit in a computer program, to make it a power of 2, just so it looks like you did it for some computer-related reason. A limit of 10 is obviously bullshit because no computer in the world has a limit of 10 for anything. Only humans use 10 as a round number. Second, if you're programming a database of names and you need to set limits on length, the least you should do is check the most common names and make sure the limit is larger than the largest one. And CHRISTOPHER has been in the top twenty of American male first names for a long, long time. Citation: http://www.catb.org/jargon/htm...

The Story of Mel

(I'd post the full text, but Slashdot complains that it has too few characters per line. Hey Whipslash -- fix it, please!)

The obligatory Obligatory XKCD

And, for "real programmers write in....:" The Story of Mel.

I always thought the banana problem in computer programming was funny. Now there are two banana problems. When will they end?

It seems that the IT monkeys have solved a one-banana problem.

Yes, it is indeed a critical part of the unix philosophy.
Generally known as the rule of optimization which The Art of Unix Programming expresses as:
"Prototype before polishing. Get it working before you optimize it"

http://catb.org/esr/writings/t...

Notice how the rule of optimization is expressed by people like Kernighan and Knuth - the kind of people who helped create the unix philosophy ?

One who breaks security on a system. Coined ca. 1985 by hackers in defense against journalistic misuse of hacker (q.v., sense 8). An earlier attempt to establish worm in this sense around 1981--82 on Usenet was largely a failure.

which would seem earlier than the parent's recollection, but it had probably been floating around in the collective engineering unconsciousness for some time. Of course, the etymology can probably be traced back to non-electronic crime, such as burglary (safe cracking/safe crackers).

You've reminded me of an excerpt from Herman Goring

21st century... The generation of children of the never-ending September grew up and the Godwin's law, instead of killing one's argument, now makes it "insightful"...

The fact is, we're not at threat from a horde of terrorists, or even a handful.

Sure, we are not. We have not enemies in the world — only friends, whose grievances we haven't addressed yet.

Eric S. Raymond: Why I joined the NRA - After 20 years of evading joining the NRA, I finally did it last week - 2016-01-03
(Yes, this Eric S. Raymond - Eric Raymond's open-source collection )

Thanks! That's really neat. I'm a Secular Buddhist (not a damned monk!) and it's interesting to note the parallels. I've read some Socrates, Plato, etc... I'm unfamiliar with this one and will have to spend more time with it. I'll probably treat them as koans and meditate on them. (It needn't be a question to be a koan.) #25 makes me think of The Prisoner's Dilemma, albeit a slightly different aspect, as if viewing it from a third party view. I think, perhaps, I'll ponder that one first.

It took me a minute but I found the download link for that one and then I went to download the plain text file and didn't like it so I remember that I'd set my browser up to enable mhtml files (single file - whole page) and I saved that. Much thanks and I'm hoping I will learn something new. From a quick scan, there are some interesting parallels between what I'm reading there and similar to some of what I'd expect to hear on refuge or whatnot.

Again, much thanks! Hmm... While certainly not as valuable, and you may already be familiar with them, I can think of no more appropriate response than to offer this:
http://catb.org/esr/writings/u...

Navigation is the funny looking squiggles in the top right and left.

You're welcome. A little research planning goes a long way... think about how many drops you want, and do your research on PVR's, etc. You don't have to rent a set-top box from your cable company, you can use your own equipment... You may be able to get three or more drops at no extra charge, ask for details. Cable lineups change frequently, study your plan online, and be aware that things can change on a month-to-month basis... I spent a lot of time educating my customers how, because of changes, that they weren't supposed to get a particular channel, or because they had a particular package, they couldn't receive the channel(s) they thought they should have. I figured thoroughly educating my customers meant that they'd be happier overall with the service...

Remember, the more research you do on your own, the less you're on the telephone, and less chance for something going wrong. Are you wanting a pro install or can you install your own cable modem? Setting up an appointment? Make sure you get the customer service rep to read all phone numbers and the address information back to you. Be meticulous with special instructions, i.e. is there a lock on the gate? Dog? If you're in a new development that hasn't been mapped yet on internet mapping services, please indicate this, or the installer may not be able to find you. Please try to get the customer service representative to spell out words phonetically (http://usmilitary.about.com/od/theorderlyroom/a/alphabet.htm). It can be a pain, but being painstaking and careful means less wasted time for you.

Don't forget to ask for specials. Oftentimes some people are so pressured to have short call times that important details get overlooked, don't let people rush you. Demand customer service excellence and attention to detail, especially when dealing with service appointments.

FCC cablecards https://www.fcc.gov/general/ca...

FCC cable television https://www.fcc.gov/general/ca...

FCC Choosing cable channels, how to file a complaint https://www.fcc.gov/consumers/...

FCC consumber guides https://www.fcc.gov/consumer-g...

How To Ask Questions The Smart Way, by Eric S. Raymond, Rick Moen http://catb.org/~esr/faqs/smar...

Yes, but have they solved the fat electron problem?

Many closed questions have what I'd call "false nuance" --- the person did not boil the question down to what is actually breaking. Their questions are scattered -- something like "I'm doing X and Y using Z library, and it doesn't work". The experts reading them can identify the problem as nothing to do with X, only a tiny bit of Y, and not in anything related to Z. They know what should have been asked, and that it's an obvious duplicate had the problem been reduced.

I don't think anyone would argue that this is helpful to the person asking the question. The real question is how far should someone go to answer a lazily written question. Especially with SO's gamification shtick, people are less likely to want to deal with questions that waste their time.

Do questions with merit get closed occasionally? Definitely. I try to reopen them when they do. But far more often than not, closed questions really should stay that way. There's this great old document How To Ask Questions The Smart Way . While StackOverflow is significantly more lax than it would have them be, it's still good reading for anyone deciding to post.

Ah, have you forgotten your teachings? There are exceptions... Indeed.

Master Foo instructed his students:

“There is a line of dharma teaching, exemplified by the Patriarch McIlroy's mantra ‘Do one thing well’, which emphasizes that software partakes of the Unix way when it has simple and consistent behavior, with properties that can be readily modeled by the mind of the user and used by other programs.”

“But there is another line of dharma teaching, exemplified by the Patriarch Thompson's great mantra ‘When in doubt, use brute force’, and various sutras on the value of getting 90% of cases right now, rather than 100% later, which emphasizes robustness and simplicity of implementation.”

“Now tell me: which programs have the Unix nature?”

After a silence, Nubi observed:

“Master, these teachings may conflict.”

“A simple implementation is likely to lack logic for edge cases, such as resource exhaustion, or failure to close a race window, or a timeout during an uncompleted transaction.”

“When such edge cases occur, the behavior of the software will become irregular and difficult. Surely this is not the Way of Unix?”

Master Foo nodded in agreement.

“On the other hand, it is well known that fancy algorithms are brittle. Further, each attempt to cover an edge case tends to interact with both the program's central algorithms and the code covering other edge cases.”

“Thus, attempts to cover all edge cases in advance, guaranteeing ‘simplicity of description’, may in fact produce code that is overcomplicated and brittle or which, plagued by bugs, never ships at all. Surely this is not the Way of Unix?”

Master Foo nodded in agreement.

“What, then, is the proper dharma path?” asked Nubi.

The master spoke:

“When the eagle flies, does it forget that its feet have touched the ground? When the tiger lands upon its prey, does it forget its moment in the air? Three pounds of VAX!”

On hearing this, Nubi was enlightened.

Not mine, obviously, but it and others are here.

No, but he and someone else are working to improve it a little, IIRC

OTOH, this guy maintains it

As far as I know, nobody has run GNU/Hurd through the Single UNIX Specification validation suite, and therefore it's apparently not eligible to have the "Unix" trademark used for it (i.e., it's not a "Unix(R) system"), and none of its code can trace its ancestry to any Unix code from Bell Labs.

No, not Unix(R), but UNIX(R). Unix is the name for the family of Unixlike. UNIX is the trademark, or at least, that's the convention people use to differentiate between Unixlikes and UNIX.

There may well be people who use that convention, but I am not one of them. Another convention that people use is to refer to Unix-like systems, whether they passed the SUS validation suite or not and whether they contain code derived from Bell Labs UNIX code or not, as "Un*xes".

The convention was created by UNIX, which was emphatic about the all-caps until recently, and not by the community.

The convention was created by the people who created it. Eric Raymond claims that Dennis Ritchie says the all-caps version stems from being "intoxicated" by the ability to produce small caps with troff and the new typesetter, and that Ritchie later tried to get the spelling changed to "Unix" in some Bell Labs papers, but failed.

The "UN*X"/"Un*x" convention was created by other members of the community (I remember it being used in USENET postings), and it's the one I use.

If you think The Hurd is Unix, then so is QNX, right?

I don't think the Hurd is a trademark UNIX or a derived-from-Bell-Labs-code UNIX. I do, however, consider it Unix-like enough to consider it a UN*X, and consider QNX at least somewhat Unix-like, although it appears that there's a lower-level API below the POSIX API that can be used.

If you want to know how Unix works, this is a good place to start.

If you want to know why systemd doesn't follow the Unix way (which means it's lousy), I discuss parts of it here.

I've heard Rust mentioned a few times so I decided to give the manual a once over to see what it is all about. First impression is that it is a very C like language, except that the memory model is highly regulated. This is good in some ways, it should be nearly impossible to screw up your memory handling with normal code making it safer by default. However, in my brief glance over I can't see any way to allocate a block of memory at runtime, which seems like a significant drawback. The language appears to have "C Programmers Disease" baked into the specification. There is a brief mention in the vector section that they are growable and live on the heap, but doesn't give the syntax for this (nor the syntax to shrink them later!). The docs also make a huge dance around "borrowing" that smells a lot like someone avoiding the dreaded "P word".

It looks like a neat language and I'm willing to give it a shot but I don't see this exploding in popularity anytime soon. There is always the chicken and egg problem with new languages that people don't want to learn it until it has a decent ecosystem, but it won't grow an ecosystem until people start using it.

Security problems have never affected the "golden age" of closed source much.

Believe it or not, at one point a very strong argument against FOSS in corporations was that software written by amateurs would be insecure and showing the code would give that away. The huge level of insecurity in MS Windows at the time made that argument laughable. This is part of the more general problems where it became impossible to say "nobody got fired for buying Microsoft" when major MS customers obviously had been fired. Quite possibly Microsofts "Get the Facts" campaign would have been much more of a success if things like "Patch Tuesday" had not driven MS Windows total ownership costs to be several times higher than the equivalent costs for Linux or OSX.

Security problems have never affected the "golden age" of closed source much.

Believe it or not, at one point a very strong argument against FOSS in corporations was that software written by amateurs would be insecure and showing the code would give that away. The huge level of insecurity in MS Windows at the time made that argument laughable. This is part of the more general problems where it became impossible to say "nobody got fired for buying Microsoft" when major MS customers obviously had been fired. Quite possibly Microsofts "Get the Facts" campaign would have been much more of a success if things like "Patch Tuesday" had not driven MS Windows total ownership costs to be several times higher than the equivalent costs for Linux or OSX.

Each script is a bunch of boilerplate that has to reimplement the same stuff.

So shared libraries don't exist? That hasn't been a problem in a long time on BSD or OpenRC systems. Seriously, it's not hard to factor out code into a library. If you're only considering Debian, you have to remember that they are always behind (sometimes FAR behind) the update cycle.

The functionality is inconsistent between services.

Again, only if you were a moron and reinvented the wheel each script instead of using a common library.

That said, the ability to do things different is very important when you need to support something unusual.

To check whether a service is running, it uses pid files.

No, there is not requirement to use PID files. That is simply a common way to implement a daemon. With sysvinit and sysvrc (or OpenRc), this kind of thing is an implementation detail that is out of scope.

It doesn't have useful logging.

Again, this is by design, as it left logging *unspecified*. If you don't like syslog, nothing was preventing you from using something else. (also, "useful" is subjective)

because init doesn't log service crashes.

Patently incorrect, as I have used syslog to inspect startup crashes many times over the last *twenty years* I've been using UNIX. Maybe this has been a problem for other people, but I've never seen it. If your syslog is configured badly, that's an entirely separate problem.

Yay for "sleep" hacks.

While I can't speak for all distributions (you seem to have had some history with poorly-configured environments), there is nothing wrong with using sleep based polling. The only reliable way to detect if a prerequisite service is ready is by directly polling the service. (e..g issue an HTTP GET to a web server) The timeout is to allow startup to proceed in case of an error, (so you don't end up bricked, unable to use your computer)

on demand

There is a reason most distributions stopped using super-servers like xinetd: on-demand startup isn't that useful. Start your service at boot. You can defer expensive tasks until the first requests, if you want, which is when you would pay that cost anyway in an "on demand" launch. Listen to on the port, block on accept(2) or select(2) or similar, and let the OS page you out to the swap partition.

"On demand" isn't necessary, because the kernel already provides that feature. Adding a redundant implementation simply increases complexity and adds more opportunity for bugs. Super-servers make it even worse, as they add the risk that a problem in on service could take down all the services provided by the super-server.

Breaks horribly the moment something goes wrong.

Ok, now you're just trolling.

Want to have some fun? On a systemd box, pretend you just installed some updates, and you need to restart a few daemons so they run the updated versions. Try restarting dbus (system, not user). (You might want to make sure any open files are saved first)

Also, you might want to actually read about UNIX before you make these kinds of accusations. Reading taoup is a good place to start.

You see. That is why being nice to people in these situations doesn't work. You mistook my "have a nice day", for "Hey I'm a friendly guy! Feel free to ask me to explain things to you!. While asking for the explanation, you didn't follow basic question asking etiquette. Why don't you actually do the work, post your question after reading esr's FAQ uncluding the actual context necessary to answer the question, and see how that works for you?

viable replacement for animated GIFs either, even though png was supposed to take care of that

That effort was borked by the Second-System Effect among the PNG developers. All they needed was a simple way to replace the animated-GIF functionality. It seems that WebM will be the replacement for animated GIFs, decades later.

(shamelessly copied from the jargon file)

Tom Knight and the Lisp Machine

A novice was trying to fix a broken Lisp machine by turning the power off and on.
Knight, seeing what the student was doing, spoke sternly: “You cannot fix a machine by just power-cycling it with no understanding of what is going wrong.”
Knight turned the machine off and on.
The machine worked.

Heck some of the most successful elements of Unix don't follow the "Unix Way" such as "do one thing and do it well". I couldn't disagree with this more. Why should a program restrict itself to doing one thing?

Yeah.....you definitely don't understand the Unix Way. That concern is addressed here. Read it.

These are philosophies not followed by Windows, OSX, iOS, Android, or even some great Unix protocols such as Xwindows. Yet the above are all examples of good systems.

Uh.....are you measuring 'good' by popularity?

Heck some of the most successful elements of Unix don't follow the "Unix Way" such as "do one thing and do it well". I couldn't disagree with this more. Why should a program restrict itself to doing one thing?

Yeah.....you definitely don't understand the Unix Way. That concern is addressed here. Read it.

These are philosophies not followed by Windows, OSX, iOS, Android, or even some great Unix protocols such as Xwindows. Yet the above are all examples of good systems.

Uh.....are you measuring 'good' by popularity?

a) "an su." Write it like you'd say it

I've never heard it said ess yoo. I tried to google it but only found threads about sudo. They were split between soodoo and pseudo. No one was arguing for ess-yoo doo or ess-yoo dough. Come to think of it, there are several words like this:

Linux: lin nux, lie nux, lee nux
SQL: sequel, ess cue el /etc: et see, ee tee see, etcetera
Even punctuation has its variants.
More fun reading.

That's a bit rude... I think Poettering's main motivation has been to simply modernize Linux.

Yeah, that's true. He sees features people want, and he builds them. For example, Debian distro builders were frustrated writing init scripts, so Poettering made something that filled the need of those distro builders. That's why it got adopted, because it contained features they wanted.

The problem of course is that he doesn't understand the Unix way, especially when it comes to good interfaces between code (IMNSHO).

The people who like systemd tend to like the features.......the people who dislike it, the architecture.

- Silently checking in 12000 lines of code in the middle of the night and leapfrogging the entire development schedule by months.
- Spending 72 consecutive hours at the keyboard, sustained by caffeinated drinks and a desire to produce an end product that will make your users - and other programmers say 'Wow!'
- Delving into the voodoo and deep magic of a system, consuming it all and spitting it back out with ease, and being regarded with awe by your peers.

Yeah, these are awesome. The Story of Mel was an early encouragement to me; between it and the movie Tron, it put me on the path to being a software developer.

Lots of folks pointed out pro- arguments, so I won't cover those, but there are an awful lot of cons. 20 years plus into my career, I'm seeing some fatal flaws.

The first is the Bus Factor. A solo developer, whether in a group or not, does not facilitate the dispersal of knowledge. There's a difference between documentation - even the elusive technical documentation - and knowledge, and that gulf widens with each feature, bugfix, and release. In my experience, when a solo developer leaves - for whatever reason - it's often easier to start from scratch than try to maintain their software.

That leads us to the next issue, maintainability. As was described above, a solo developer can skip quite a bit; coding style, documentation, modularization, naming schemes, readability, unit testing, automated build and deployment, and so on. I've had to take over so many projects in my life that required more time to set up a working build and test environment than they did to fix the error I had been brought in to tackle. I used to carry a pack of cd's with precompiled versions of sed, awk, as, and other tools for various *nix platforms (and versions of those platforms) because these were often not just pre-requisites for the often complex script-based builds, but often only came in for-pay packages that weren't on the machine I was expected to work off of. I had a set of about 30 just for HP-UX alone (because you have no idea which version-specific behavior a given build relies on). Put it this way: every build required a port.

Of course, it's not just other people's code. I'd come back to something I wrote a year prior and it'd be horrible.

"Why did /THEY/ do this? Wait ... did I do this? Geeze, I USED to write bad code." - me, every. single. time.

I have a theory that only constant modifications to code keeps away the gremlins that cause bitrot. Leave a piece of code alone for a month, no commits (assuming you're even using version control), and they come in and crap all over your beautiful hacks and graceful architecture, rendering it just barely capable of doing what it was designed to do, and sometimes not even that. Yet, you write your code as if a team will handle it, losing most of the benefits of being a solo dev, and it's usable when you come back to it later.

Communication is next, and it ties into the maintainability above, but on a software development lifecycle level. When someone is silently making architectural changes and off doing their own solo thing, sure, they get a lot done. When you're completely by yourself, that's fine. What happens though, when you're doing solo development in a large company? Suddenly there's no code reviews, no understanding of department or organization architectures, or even just updates to them. Your code usually stands on the back of a whole architectural stack, and without two-way conversations, it isn't guaranteed to hold up. It's not just that you might accidentally reinvent the wheel - it's that you could do it wrong and limit the application (or have it die) later, with an expensive to fix systemic issue. Documentation fits in this category too - and why do documentation when you're a solo dev? You can always answer any question, right? Yo

So have I......so what? When Poettering writes straight code, it's pretty good. I would be happy to have him as a coworker. The problem is when he starts architecting, that's where he lacks skill. He would be wise to read some basic documents on the topic.

You will find he has read all the classic Unix books, and unlike most others actually studied Unix variants and Unix code beside Linux.

All the systemd tools are made with regards to classic Unix philosophy, they only do one thing and they do it it well, they aren't chatty when scripted, doesn't report success (error code 0) as default, aren't interactive, etc. You often see Poettering quoting directly or indirectly from Ken Thomson et al. on the systemd mailing list. systemd closely follows classic Unix tradition where it actually makes sense.

You are severely underestimating his abilities; making a program like Pulseaudio, a middle-ware layer between the kernel/ALSA stack and userspace, was insanely difficult, but an instant success that solved many real world problems that especially DE developers had, and that made it default on all major Linux distros early on.

Yeah, I know some people likes to claim that PA doesn't work on their broken distro, but the fact is that no one has ever even tried to replicate what PA does, even now where all the ALSA/kernel driver bugs have been shaken out.

The fact is that PA was both well done and brilliantly pulled off. And it wasn't a "lets rewrite everything from scratch, including every sound card driver in the kernel" solution, but a solution that maximized existing work and with a smooth transition with no "flag day".

Same with systemd; using Fedora the transition from Upstart to systemd was really smooth; no "flag day" where either only systemd or sysvinit scripts worked, all the usual commands like telinit or "shutdown -h now" still worked, and all the SysVinit scripts worked too.
It really is impressive how smooth the technical transition to systemd went on RHEL, Fedora, Suse, Arch and Debian, despite it replacing several different init-systems and rather different environments.

Then sometimes he makes amusing rookie mistakes. So that's where he is as a programmer: good code, poor design.

systemd is really portable across architectures, which is the important bit for Linux. That you can't easily port it to BSD is totally irrelevant : systemd is GPL/LGPL so it can't be close sourced and therefore it will never be adopted by BSD since close sourcing software is what pays their developers.

Anyway, you can't port BSD system software to directly Linux either; it isn't made that way, neither are official system software from Unices like Solaris. The "Unix wars" are over; Linux and Open source won, the proprietary Unices have been delegated to tiny niche domains. It makes no sense whatsoever to make systemd portable to SCO Unix, or AIX.

I saw an interesting comment from Poettering regarding OpenSSL code pre-Heartbleed; he found it abysmal. And it is exactly "Heartbleed" style bugs they want to avoid, where someone drops a turd of a patch into the repo that circumvent security measures, just so some proprietary close source Unix can avoid upgrading its libraries.

Anyway, I think you are severely underestimating his abilities as software architect; he has at least 3 major projects under his belt that now all are part of every major Linux distro. Two of those projects so inherently hard that many developers had given up trying to solve the problems.

Don't give me that crap;

STFU? Anyone can insult, it doesn't make your point stronger.

Poettering has a CS degree and has coded Linux for +10 years now,

So have I......so what? When Poettering writes straight code, it's pretty good. I would be happy to have him as a coworker. The problem is when he starts architecting, that's where he lacks skill. He would be wise to read some basic documents on the topic.

Then sometimes he makes amusing rookie mistakes. So that's where he is as a programmer: good code, poor design.

Not studying systemd is simply professional suicide when it comes to Linux.

Thanks, I appreciate the concern. I don't make money based on my ability to use whatever software, I make my money designing good software. Although I've spent plenty of time studying systemd, so my career is safe.

btw, that points to the difference between people who like systemd, and people who don't. Those who favor it tend to look at the features, and say they are decent. Those who dislike it tend to look at the design, and say, "that's kind of wonky." A person can hold both opinions, they are not logically inconsistent. Unit files clearly fill a need people have.

The whole thrust of ESR's Cathedral and the Bazaar essay was aimed at the contrast of the old 'cathederal' method of software development and more open systems. In fact, the 'Cathedral' being criticized was the GNU Emacs team. (Many people miss this fact and assume the 'Cathedral' being criticized was Microsoft or some other entity that they don't like).

The 'Priesthood' was the elite in charge of GNU Emacs development. Many Open Source projects have evolved in that direction, which is justified in that random-anyone can't just wander in and start committing patches. The contradiction is perilous.

Makes me think of the magic / more magic switch story. http://www.catb.org/jargon/htm... in case you have never read it, worth the time imho.

The only agenda the Geeks have is to call allegations of sexism bullshit. Correlation is not causation. Even if the study were accurate we can't jump the logic shark and wind up at sexism without evidence. That's like saying hospitals make people sick because we find a concentration of sick people at hospitals.

The anti-woman Geek-culture has always been a myth. When we did some research on actual geeks in tech in the 90's we found this:

Hackerdom is still predominantly male. However, the percentage of women is clearly higher than the low-single-digit range typical for technical professions, and female hackers are generally respected and dealt with as equals.

In the U.S., hackerdom is predominantly Caucasian with strong minorities of Jews (East Coast) and Orientals (West Coast). The Jewish contingent has exerted a particularly pervasive cultural influence (see Food, above, and note that several common jargon terms are obviously mutated Yiddish).

The ethnic distribution of hackers is understood by them to be a function of which ethnic groups tend to seek and value education. Racial and ethnic prejudice is notably uncommon and tends to be met with freezing contempt.

When asked, hackers often ascribe their culture's gender- and color-blindness to a positive effect of text-only network channels, and this is doubtless a powerful influence. Also, the ties many hackers have to AI research and SF literature may have helped them to develop an idea of personhood that is inclusive rather than exclusive — after all, if one's imagination readily grants full human rights to future AI programs, robots, dolphins, and extraterrestrial aliens, mere color and gender can't seem very important any more.

Apparently, Geeks will level the same sort of "freezing contempt" against people who baselessly accuse them of sexism or racism since they're some of the more open minded people on the planet. Know who does have an agenda though? The Bilderberg Think Tank and the Gates Foundation who manufactured the (women in) STEM crises. Not enough women in tech? Give us more H1Bs and we'll fix that! Ugh.

Yep, here are the old school definitions:

http://www.catb.org/jargon/htm...

It's a shame that the term for something annoying but ultimately harmless (and on occasion quite witty) has been hijacked as a term for unacceptable abusive behaviour.

replace it with "float64_t", and the fore mentioned long double with the clear "float80_t"

Looks like "Everything's an x86" has replaced "Everything's a VAX".

Hint: there are other CPUs in common use that have C compilers. Some still even have 16-bit int (MSP430). foonn_t types are aliases to actual types that let the programmer know that the type is the size expected, particularly for integer types. Those basic types still need to be in the compiler so that stdint.h has something to alias into the "standard" types.

That being said, programmers unironically using types like long long and long double is indeed a Bad Thing.

and I'm not even talking about MS's hacks of __int32, __int64

You also forgot the BYTE, WORD, LONG, etc. types all over the Windows API. Sure, they're older than stdint.h, but they're yet another buttload of type aliases to keep track of.

Does anyone want their div by zero errors to result in anything other than zero?

I want a divide-by-zero error that occurs in properly validated data to result in a HCF command being carried out.

Further more, I want people writing code for me to actually understand what they're doing, and to analyse their algorithms so that they check data going in, and trap for errors. Yes, it's time-consuming and difficult. But it's also necessary.

On a Vax you could dereference a NULL pointer and get zero.

http://www.catb.org/jargon/htm...

The Eric S Raymonds jargon.txt or "The New Hackers Dictionary" has a series of illuminating illustrations on the features of a water-powered computer, made by Bells & Whistles incorporated.
No cooling problems, good floating point performance, but the overflow error and subsequent core dump is to be taken seriously ...

See http://www.catb.org/jargon/htm...

Being able to do a "journalctl -b -1 -p err" is so much better than faffing around with grep and regex.

That statement alone shows the core problem with the systemd evangelists: you don' t want to learn generic tools, and instead want to use single-purpose, monolithic[1] apps. A key distinction between the two this windows-style "fancy speciality apps" idea and the design goals of UNIX-like environments is that someone has already implemented the query you want to ask the computer to run.

It's great that you found a useful way to view your log data. Now try to query on something that journalctl didn't already implement for you. What kind of query? I don't - and that's the point. We can't predict the future, and new problems show up all the time. The point of what you call "faffing around with grep and regex" is that those tools are not difficult to use, and once you are familiar with the basics you now have a general tool you can apply to any unexpected situation.

syslog severity level "error" and above

I have never even remotely needed to filter events by syslog(3)'s "level" bits - it's not a very reliable filter, as app can be inconsistent in what LOG_* flag they use. Filtering on the facility (source) or time is far more useful. If you find that particular command to be useful, then great - which would be a good example of how use-cases can vary a *lot* depending on what you're doing.

try that with grep!

Listen, if you want lessons on how to use basic unix tools, there are many available on the web. For now, what you're obviously missing is that you would use sed for range filtering, not grep. do the line-range filtering. You simply use two regex in the form sed -n '/start_line_pattern/,/end_line_pattern/ p'.

Then, once you have a useful query built with the standard tools, you save it in a 2 line shells script. Seriously, do you think we actually type this stuff out verbosely every time we want to search a logfile? Have you evne *used* a CLI? This is n00b level stuff.

how can systemd ever make it harder for non-systemd distros

If you're going to accuse someone of being misinformed, it's a good idea to actually know what you're talking about. To name the most obvious example, it is absolutely insane to have any specific application (server daemons included) depend on any particular "init system"2. Yet systemd promoted the idea of using sd_notify which created a link-time dependency. Yes, such things can be compiled out, but that misses the point. Introducing a binary, link-time dependency like this has the de facto effect of forcing distros to make an all-or-nothing choice about including systemd.

It is true that this is not entirely systemd's fault - the app/sever authors are also to blame for going along with this crap. That doesn't excuse all the social pressure Poettering's cabal put on a lot of projects.

1before anybody trolls with the usual response that systemd is not monolithic - probably by mentioning the number of binaries it compiles into - you should know that those claims will only prove you haven't actually understood what we mean when we say "monolithic"

2 this is why it was always a lie to call the systemd takeover a debate about "init systems", as systemd was never just an "init system", but also many other things as well, mostly inseperable by design

Being able to do a "journalctl -b -1 -p err" is so much better than faffing around with grep and regex.

That statement alone shows the core problem with the systemd evangelists: you don' t want to learn generic tools, and instead want to use single-purpose, monolithic[1] apps. A key distinction between the two this windows-style "fancy speciality apps" idea and the design goals of UNIX-like environments is that someone has already implemented the query you want to ask the computer to run.

It's great that you found a useful way to view your log data. Now try to query on something that journalctl didn't already implement for you. What kind of query? I don't - and that's the point. We can't predict the future, and new problems show up all the time. The point of what you call "faffing around with grep and regex" is that those tools are not difficult to use, and once you are familiar with the basics you now have a general tool you can apply to any unexpected situation.

syslog severity level "error" and above

I have never even remotely needed to filter events by syslog(3)'s "level" bits - it's not a very reliable filter, as app can be inconsistent in what LOG_* flag they use. Filtering on the facility (source) or time is far more useful. If you find that particular command to be useful, then great - which would be a good example of how use-cases can vary a *lot* depending on what you're doing.

try that with grep!

Listen, if you want lessons on how to use basic unix tools, there are many available on the web. For now, what you're obviously missing is that you would use sed for range filtering, not grep. do the line-range filtering. You simply use two regex in the form sed -n '/start_line_pattern/,/end_line_pattern/ p'.

Then, once you have a useful query built with the standard tools, you save it in a 2 line shells script. Seriously, do you think we actually type this stuff out verbosely every time we want to search a logfile? Have you evne *used* a CLI? This is n00b level stuff.

how can systemd ever make it harder for non-systemd distros

If you're going to accuse someone of being misinformed, it's a good idea to actually know what you're talking about. To name the most obvious example, it is absolutely insane to have any specific application (server daemons included) depend on any particular "init system"2. Yet systemd promoted the idea of using sd_notify which created a link-time dependency. Yes, such things can be compiled out, but that misses the point. Introducing a binary, link-time dependency like this has the de facto effect of forcing distros to make an all-or-nothing choice about including systemd.

It is true that this is not entirely systemd's fault - the app/sever authors are also to blame for going along with this crap. That doesn't excuse all the social pressure Poettering's cabal put on a lot of projects.

1before anybody trolls with the usual response that systemd is not monolithic - probably by mentioning the number of binaries it compiles into - you should know that those claims will only prove you haven't actually understood what we mean when we say "monolithic"

2 this is why it was always a lie to call the systemd takeover a debate about "init systems", as systemd was never just an "init system", but also many other things as well, mostly inseperable by design

I know this isn't directly related, but it's the first thing I thought of (and it's a good story anyhow). http://www.catb.org/jargon/htm...

If you don't have any meetings, how do you know what your coworkers are doing?

Most of the time they are orking cows.

Why not a gripping hand?

Randomly swapping system components to see what's broken? Where have I heard that one before:

Q: How can you recognise a DEC field circus engineer with a flat tire?
A: He's changing one tire at a time to see which one is flat.

Q: How can you recognise a DEC field circus engineer who is out of gas?
A: He's changing one tire at a time to see which one is flat.

http://www.catb.org/jargon/html/F/field-circus.html

you know what makes a good UNIX or UNIX-like operating system? The tools, specifically those that are well-written and do one thing and do it well

This link has a pretty good summary. I summarize the Unix way as "write good code."

Systemd is a collection of small executables each with a precise goal, in line with the UNIX philosophy.
Do a "ls -alSrh /lib/systemd/systemd-* /usr/bin/systemd-*" if you want to verify this fact.

Try running any one of them independently of the rest.
Just because the program is broken into smaller pieces does not a make it in line with the unix philosophy.
I can currently run swap out any of the alternate unix util's be they GNU, BSD, Solaris, whatever, Plan9 even utils even.
I can use OpenRC for my init, dcron from DragonflyBSD for my cron, Dtrace from Solaris, pf packet filter from OpenBSD, and Plan9 user space utilities on any number of kernels including Linux.
SystemD utils can only be used on one kernal with sytemd as the init. I can't use networkd for examplwith systemV init or openRC.
Secondly SystemD eschews the unix philosophy that plain text is the universal interface and avoidance of binary format when possible, instead it embraces binary output for its logs for example requiring a yet another component to even be able to read your logs.

Since you seem be mistaken in understanding what the unix philosophy is you may want to review what the jargon file say about it.
http://www.catb.org/esr/writin...

It's not a rollover bug; It's a rollover feature!