Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
Note: You can take 10% off all Slashdot Deals with coupon code "slashdot10off." ×

Comment wire wrap serial interface (Score 2) 210

The Commodore 64 had a nonstandard serial port, meaning that I couldn't connect my standard RS-232 modem directly to it. Being just a kid, I couldn't afford the $50 or so that an adapter would cost.

My solution: I borrowed a family friend's RS-232 adapter, opened it up, examined the components and circuit board traces, bought the parts from a local electronics shop, and built the same circuit with perfboard and wire wrap. I cut a slot in the back of my C64, mounted a DB-25 connector in it, wired it to my frankenboard, and stuffed the whole thing into the free space inside the computer.

It worked like a charm. I was the only kid I ever met whose C64 had a standard serial port on the back.

Comment Re:Experts... (Score 1) 345

C++ gives a nice balance between high performance and relatively good safety.

Huh? Relative to what?

C++ was my primary language for quite a few years. I was very good at using it effectively while introducing far fewer bugs than most coders I encountered, but I would never call that language anything near safe.

Maybe you're talking about a subset of C++ that does not include things like pointers and arrays?

Comment Re:Why do people dislike systemd so much? (Score 1) 229

All it takes is the motivation, a group of likeminded individuals and the willpower to deliver a dist that does not use systemd. I expect most packages in the debian universe have no deps on systemd and therefore no work required to support those packages. So we're talking system packages, some daemons and maybe a few shims for edge cases.

You're implying that it would be easy. I'd like to think you're right. One group has already announced such a derivative. I'd love to see it succeed, but I'm not holding my breath. Maintaining a linux distribution as well as debian does, including timely security updates, package builds, downstream bug tracking, release management, and uniformity across so many installations as to form a vast support community, is a much bigger job than one might think. There's also the issue of various unrelated but popular packages developing dependencies on systemd, which means any such derivative distro would also be in the business of developing and maintaining forked versions of those packages; also not a trivial task. I guess we shall see.

As for why there are only 2 dists left not to have gone to systemd, perhaps that should serve as a clue in itself.

Many of them seem to be derivative distros that simply don't want to diverge from their upstream distribution's init system, so they have little choice. (Counting them as independent decision makers would be dishonest.) As for the upstream distros, I think it's more telling to note how very divided their communities were in the vote for/against systemd. A strong argument could be made that anything so integral to the core of an OS distribution should not be replaced with something so divisive to the community.

Speaking for myself, I'm a bit disappointed in the loudest factions of this disagreement. Most of what I see in these discussions is two mobs of people pushing for a decision *right now* (meaning this year, or next). The voices shouting "we need systemd!" or "we need nothing of the kind!" dominate the discussion, while a third option seems to have been forgotten: How about waiting until something can be developed that offers important core improvements over sysv init, but isn't as invasive as systemd? Most of us can obviously get by just fine with our existing init systems for a little longer; we've been doing it for years. The uproar over the topic is surely enough to motivate the development (or modification) of an init system that most of the community would find suitable. I'd love to see that happen.

In any case, I think the original question here has been answered. :)

Comment Re:Why do people dislike systemd so much? (Score 1) 229

This is where the exercise of free will kicks in. If you cannot contemplate learning something new, stick with what you have or choose a dist that chooses to do stuff the old way.

Thanks. You just provided yet another example of the same old fallacious argument. It completely ignores two important facts: The only alternative distributions left are either so anemic in their overall support that they would utterly fail as substitutes (debian's software archive is second to none) or are so different that a migration of any significant size would be unreasonably painful (let's see how long it takes you to migrate 50 machines to gentoo, let alone maintain it with 500 machines). Anyone who makes the argument you just made either has no grasp of the real-world issues, or is being disingenuous.

Comment Re:Why do people dislike systemd so much? (Score 3, Informative) 229

The reasons for disliking it vary, but there is at least one common thread among those who are upset about it: Systemd is being shoved down their throats, in that several of the most widely used, widely loved, deeply entrenched linux distributions have announced that they are adopting it. Many people who use those distributions do so for very good reasons, and since there are no equivalent alternatives, these people are being forced to either accept systemd (which will cause them unwanted trouble) or migrate to an inferior distribution (which will also cause them unwanted trouble). That kind of thing is enough to piss anyone off.

Comment Git is its own worst enemy (Score 3, Insightful) 203

Git is its own worst enemy

Sigh... Git. Ten years later, and it's still making people suffer with its unforgivably awful user interface. Seriously. I like the command line, and git is my primary version control system, but git's UI is the single most user-hostile example of human-computer interaction that I have had the misfortune to encounter in years. Maybe decades.

Git's command structure is a train wreck of inconsistencies, some of its most important terminology is worse than worthless, and its man pages and built-in help text are idiotically obtuse. I have been following its development closely enough to understand how it got this way. A lot of it has to do with placeholder terms that were never updated, synonyms that were never reconciled, features that were grafted onto existing commands and never properly organized, and its origin as a set of low-level components rather than a tool intended for humans. In other words, a pattern of evolution much like any other software, except for one thing: Even after years of being relatively stable, its mantainers still haven't addressed its glaring usability problems.

These aren't just minor warts that only affect a few people, either. There are countless articles, blog posts, and forum threads expressing frustration with git and detailing specific improvements that could transform it from a usability nightmare to an elegant piece of work. Sadly, the maintainers either ignore them or respond with some half-witted reason to resist change. Frankly, I am embarrassed to see my fellow software developers failing so miserably to recognize the importance of usability, and failing to fix it.

What is the cache? It's a place where you're expected to manually arrange your data before you commit it. Does it function like a person would expect a cache to function? No, but we call it that anyway. What is the index? It's the same thing. Does it function like a person would expect an index to function? No, but we call it that anyway. You're referring to the same thing in both cases? Yes, for the most part. Does it function like anything that might be familiar to anyone? Yes, it's essentially a staging area. Why don't you call it a staging area? We do, but only in the minority of cases. You mean you have three names for the same thing, and the most accurate name is the one that you use the least? Yes. Why? Because the meaningful name might be harder to translate into other languages. So you deliberately use a confusing variety of misleading names when writing in English, the single most widely used language in computer science, because one of your translators didn't want to describe a staging area in another language? Yes. Well, that's probably okay, because this thing is probably some obscure piece of git that most people don't have to use, right? No, it's actually one of git's most distinguishing features, and interacting with it is absolutely required in order to use git. I see.

Newcomers shouldn't have to be encouraged to "take the time to learn git." It should be easy. A programmer familiar with version control systems should be able to pick up a new one in five minutes, and find the answer to most intermediate-to-advanced problems in maybe ten or fifteen. They should be able to walk away for a month or two, come back, and still remember how to use it. That doesn't generally happen with git. One has to invest quite a bit of time and patience to confidently use anything beyond its most basic operations without screwing something up, and stay in practice with it, or else end up having to learn most of it all over again.

The ridiculous thing is that it doesn't have to be this way. Mercurial is real-world proof of that.

I hate git for these reasons. It's a cantankerous bastard of a tool that will just as soon kneecap you as handle your data. I only use it because of github (which is brilliant, by the way.) If you want to see an example of how version control should be done, get to know mercurial. Its internal design is similar to git's, and it can do pretty much everything that git can, yet it has a sane user interface.

Here's an astute bit of satire:
http://git-man-page-generator....

Adding manpower to a late software project makes it later. -- F. Brooks, "The Mythical Man-Month"

Working...