Pascal might be underrated but it doesn't matter. There is no place for Pascal in the modern programming world.

When I went to college, Pascal was the standard teaching language. I have studied it pretty thoroughly and I understand it pretty well.

Pascal was designed as a teaching language. There are features in Pascal that are stripped-down, and I think it was just to make the teaching easier. In particular, why must all goto labels be integers rather than strings? I'd much rather write goto cleanup_after_fatal_error than goto 1000. It was a tiny bit simpler to write a Pascal compiler because of this limitation.

If you know C and really want to understand why Pascal didn't win over C, get a copy of Software Tools in Pascal. Look at all the places they had to work around limitations in Pascal, and consider how to write similar code in C. In all the cases, I realized that they simply wouldn't have had a problem in C.

Also, after writing the above book, Brian Kernaghan wrote an essay Why Pascal Is Not My Favorite Programming Language and if you have rose-colored glasses for Pascal I suggest you read it.

C really is the king of the "third-generation languages". In its earliest form it had dangerously little type-checking, but in its modern form (where you use function prototypes so the compiler can check types) it has type checking similar to Pascal, with all the benefits that provides. And it has all the little things I appreciate, such as terminating a loop early using break. In Pascal, to terminate a loop early you needed to either clutter up the loop conditionals with an extra flag variable (early_exit or some such) or else you had to use goto to break out (with a numeric label target, of course).

"But wait," some of you are muttering. "I used to write Pascal programs and I remember using break..." No, you didn't used to write Pascal programs: you used to write Turbo Pascal programs. When Borland created Turbo Pascal they fixed all of the worst problems of Pascal, pretty much by just doing whatever C did first. I wrote a lot of Turbo Pascal and I liked it very much.

But this points out the biggest problem of Pascal: it was not well specified, and as a result it didn't work a lot of the time. Where a spec is weak, you tend to get different implementations doing different things, which is horrible for portability. The wonderful book Oh, Pascal! discusses the brokenness of the I/O in Standard Pascal, and the various ways that Pascal implementations work around the problem, and summarizes with Cooper's Law of Standards: "If it doesn't work, it doesn't stay standard."

For Pascal to have a niche, it should do something a lot better than C, for it is C that it needs to displace. But IMHO there really isn't anything it does very much better than C, and there are numerous areas where it's a non-starter unless it copies features from C.

Given the massive installed base of C, C isn't going anywhere, and that leaves no room for Pascal; Pascal does the same sort of things as C does, but not as well.

So when things are wrong a frequent reason to use such a command is used), it wastes my time to display something I didn't request and don't want to see.

When things are wrong, you don't want to see the recent log events to diagnose what went wrong?

It's a legit complaint if this display slows you down, but I'm amazed that you are so hostile to the idea. However, as a sysadmin I'm just a dilettante so I will defer to your expertise.

Citation needed? I seem to remember that X could also run as non-root before systemd.

http://hansdegoede.livejournal.com/14268.html

The main problem with systemd is that it is beeing pushed onto and by the mayor distributions without fixing the problems first.

Makes sense to me. I'm glad that Debian did the work to leave SystemD as optional.

0) Okay, I agree that I should have phrased that differently. Note that I didn't use a pejorative phrase; I didn't say something like "morons too stupid to understand the greatness of SystemD" or whatever. I really only meant to say "some people who strongly disapprove of SystemD do not want it involved in logging at all."

1) I hope you didn't intend to lump me in with "systemd people" because I'm not one. I am an interested observer looking in from the outside. To the extent that I care about Linux and its future, I care about SystemD; I've been trying to understand how good or bad it is.

But the vast majority of the criticism I have read of SystemD has been just opinion-based flaming. To read most of the posts on Slashdot, there must not be anything good about SystemD and the people who choose it must be deluded or fools or something. I wanted to push past that and understand why smart people might not reject SystemD.

for those of us that use 'sed' and 'grep'

I'm quite skilled with grep so I can query plain-text files just fine, but I'm not opposed to SystemD making a binary log with an index for its own purposes.

If you set up rsyslog or whatever, you will still get a plain-text log file, and you have the option to simply ignore SystemD's own log file.

Windows style 'Services' (your word)

No, don't lump me in as a "systemd person". And don't assume that I'm your enemy or something.

And don't ask "how are they forcing" again, that isn't helpful when I can't get just turn the package off and sysv init on.

In Debian "jessie" you can do just that.

https://wiki.debian.org/systemd#Installing_without_systemd

systemd insists on binary logs

My understanding is that SystemD makes binary logs for its own purposes, and that the binary features include indexes so it can very quickly answer queries like "what were the last ten things logged by Apache?"

However, SystemD permits continuing to run a time-tested conventional log daemon. The current recommended way to get network logging is to run rsyslog.

Some hard-core SystemD haters are still not happy, because the log events flow through SystemD on their way to the conventional log daemon.[1]

takes over vast chunks of functionality that it has no business touching

I'm not certain this really is the case. SystemD is a collection of services, and each one has a specific area of concern. The actual technical analyses I have read suggest that the basic design of SystemD is sound, and that it is doing things that people want to be done. For example, SystemD allows the graphics system (X.org) to run as a non-root user.

One criticism of SystemD that may have some validity: that the only documentation is whatever the source code contains this week. SystemD is being developed at a rapid pace and documentation may be suffering. This is one reason I am glad for projects like UselessD... they will force the SystemD interface to settle down a bit and be documented a bit better.

But I'll say it again: from what I have read (in technical analyses) the basic design of SystemD seems to be sound. The Debian technical committee that evaluated the situation concluded that SystemD was the best choice for Debian. (Then the politics blew up but that's another story.) Do you think that the Debian technical committee spent months evaluating SystemD and were just wrong about it? (That's not to say that SystemD is perfect. But something can be imperfect and still be the best choice for the future.)

makes it basically impossible to debug problems

I will not comment on this because I have no experience with SystemD yet. I have seen comments like this multiple times.

Perhaps, even if SystemD is the future, it should be adopted slowly and carefully in the present. Debian "jessie" has SystemD as optional which seems like a very good thing to me.

[1] I think that's probably an overreaction... if Red Hat can't get SystemD to reliably pass through log events, that would imply a level of brokenness that would preclude the widespread adoption that seems to be taking place.

Huh, I didn't think that was a troll when I wrote it. But it has been modded as Troll twice now.

Well, I really do prefer to give my money to AMD and I really would buy the fanless mini-PC in TFA.

remember when the speed would double and the cost would halve like clockwork? Those days are gone forever.

True. If you buy AMD processors, you aren't getting the fastest possible, but they will still be plenty fast enough. I built my wife's computer with an AMD FX-8350 and she's very happy with it (and I want one for myself).

And as I said, I would be happy to buy the tiny computer discussed in TFA. Sounds neat. (I'd also be happy to buy a tiny computer based on an ARM chip, but I'd rather have full Linux than just ChromeOS so I probably won't buy a "ChromeBox".)

My feelings towards big UPSes is that the battery only lasts a couple years, and costs a ton to replace.

Just make sure to buy a UPS that takes a standard battery. All my UPSes will accept a standard 12V 9ah battery (search for "UB1290") which you can get for $20 or less. I bought a six-pack from Amazon for $100 or so.

It pays to buy a decent UPS with decent status reporting. I have some old ones that I bought cheaper, and they don't report how loaded they are (they have a single "overloaded" light that lights and another single "battery problem" light). My better ones have a little bar graph for how loaded the UPS is, and another bar graph for how charged it is, plus various status lights.

My old UPSes can report status through a serial port, but my newer ones can report through USB. Again, do your homework: some UPSes use a wacky undocumented proprietary protocol, while others are just plug-and-work under Linux. (But I haven't spent any time messing with this yet.)

Also, when your UPS goes into battery fail, replace the battery right away. If you leave the battery too long, it can cook, swell up (from expanding gases I guess) and be difficult to remove from the UPS. <shifty_eyes>Not that I am speaking from experience..</shifty_eyes>

I wonder, though, if the benchmarks were made using code compiled with an Intel compiler.

http://yro.slashdot.org/story/05/07/12/1320202/amd-alleges-intel-compilers-create-slower-amd-code

Oh, but surely by now they have stopped doing it? Nope:

https://software.intel.com/en-us/articles/optimization-notice

(Isn't it cute how the legal notice is embedded in an image file, so it's hard for search engines to find it?)

It really is true that Intel chips are better than AMD chips now. Intel has fixed the problems in their chips (the Pentium 4 had serious issues) and Intel is two generations ahead on semiconductor process technology.

Intel could be beating AMD fair and square, yet they still engage in the sleazy underhanded practice of making their compiler sabotage the competition.

Intel's remaining chip problems are self-inflicted: they want to maximize the dollars they extract from the customers, so they make a bunch of different chip versions, and different versions have features enabled or not. AMD is #2 and trying harder, so AMD chips always have all features enabled.

So I would be willing to buy one of these AMD-based mini PCs. It will be slower and/or consume more energy than an Intel version; but I just plain don't approve of Intel, and its performance will be adequate. I'm not going to be computing digits of pi on this thing.

P.S. The best thing I can say about Intel: they have cooperated well with the Linux kernel team, and Linux support is great for Intel chipsets including graphics accelerators.

But AMD is doing a pretty good job of cooperating with the Linux kernel guys, and I'd rather give AMD my money.

A few years ago, a relative bought a new laptop that came with Windows Vista. She asked me for help putting her QuickBooks onto it.

Her version of QuickBooks simply wouldn't run on Vista. So I went to the store to buy an upgrade. I carefully studied the feature lists on the boxes for the various versions, trying to figure out which one she needed. For $100 I got some version ("Express" or "Starter" or something like that). It had all the features she needed and was $100 cheaper than the next version.

It turned out that it was missing one key feature: it didn't support upgrading! It would have been fine for her if she had started out with it, but because she was upgrading from an old version, she had to get the $200 QuickBooks. That's right, her reward for being a long-time customer was to pay $200 instead of $100 for a version that would run on Vista. (And it really didn't say on the box that upgrading wasn't supported. I had to figure it out... when I couldn't find an "import" dialog in the menus, I searched their web site; and I found a knowledge base article that plainly spelled out that importing was a feature reserved to the $200 and above versions.)

If I ever start a home business, I'll run it on some open source system. No Intuit products for me, not ever.

The Seahawks stadium is designed to be loud. It tends to focus noise rather than dissipate it.

http://en.wikipedia.org/wiki/CenturyLink_Field#Home_field_advantage

http://www.businessinsider.com/seattle-seahawks-stadium-loud-2014-1

http://mynorthwest.com/25/702605/Why-NFLs-new-noise-rules-may-hurt-the-Seahawks

I guess the fans like to do loud things like stomping as well. So this really is the right place for this sort of experiment.

Is anyone here old enough to remember those languages . . . ?

For a brief period I worked with SNOBOL. I was reading old SNOBOL programs and re-writing them in AWK.

The AWK programs were smaller and simple to understand. The SNOBOL programs were hard to figure out... I would describe the process almost as "reverse-engineering".

SNOBOL's design dates back to the bad old days. It has "goto" hard-wired into the language; it has "fields" where you put certain things in certain places on the line, and then the control flow changes via goto branching. One field is the "goto on success" field, another is the "goto on failure" field. I didn't like this.

Even worse, the specific implementation of SNOBOL that we were using used simple recursion with backtracking for pattern matching, and it was possible for some patterns to consume unreasonable amounts of time. As a result, the SNOBOL contained a "heuristics" feature that would decide if a search seemed to be taking an unreasonable amount of time, and terminate the search early. Since there were valid patterns that could take that much time on valid inputs, there was also a global variable to switch the heuristics off, so you could force it to wait long enough to get a correct result if that occurred.

AWK, on the other hand, compiled regular expressions into a deterministic finite state automaton that would make one state transition per input character. It was so much faster than the SNOBOL programs.

So SNOBOL was hard to write, hard to understand, and had terrible performance. Other than that I guess it's okay.

http://everything2.com/title/SNOBOL

You might be happier if you pair your Pono with an O2 amp. The O2 was designed to be portable.

http://nwavguy.blogspot.com/2011/08/o2-details.html

If you like to solder you can build your own; the plans are open-source.

I don't like to solder and bought one pre-made from JDS Labs. I didn't care about portability and I wanted to use it with a computer so I bought the O2+ODAC all in one.

http://www.jdslabs.com/products/48/o2-odac-combo/

You can spend more money, but you really can't beat the performance of an O2 and/or ODAC. You can spend less money but whatever you get won't be as good.

Certain instruments just don't encode very well.

True.

I used to work for James D. Johnston ("JJ") who was the co-inventor of MP3 while he was at Bell Labs. He told me that MP3 has a particular problem with reproducing the sound of a glockenspiel.

He was never happy with MP3. My understanding is that the standards process forced him to compromise the design in ways he didn't like, and later when he did AAC it was more like what he had wanted MP3 to be all along.

http://apple.slashdot.org/comments.pl?sid=2497684&cid=37865994

I think the thing being missed here is that people are in a hurry.

I think you didn't read TFA. Relevant:

The VIPs are leaving the carriers, driven away by the security annoyances and drawn by the convenience of much smaller jets that come when they call.

For rich people, time is the only thing money can't buy. A [hypersonic aircraft] flying between fixed hubs along pre-timed flight paths under conditions of high security is not convenient. A bizjet that flies at their beck and call is actually speedier across most intercontinental routes, unless the hypersonic route is serviced by multiple daily flights—which isn't going to happen unless the operating costs are comparable to a subsonic craft.

I know that if I had the money, I'd prefer to fly by bizjet. If I'm 5 minutes late it is still there waiting for me, and it flies from where I am directly to where I need to go... that's pretty hard to beat.

And he's right that governments will get really nervous about hypersonic craft. As he says in TFA, the hypersonic flight could stick to its planned flight path and then deviate only for the last 20 minutes, and still be able to hit an arbitrary target. With less time to react to the threat, government will try to preemptively secure each flight, which means the already-inconvenient airport security will get even more inconvenient.

Thus his point that even if hypersonic airplanes were available to them, rich people would rather fly a subsonic bizjet with minimal hassles (and with Internet available during the flight) rather than get to an airport on time, wait in the security holding pen with all the other common horde, undergo intrusive security procedures, fly really fast to whatever hub airport the hypersonic flight goes to, and then likely have to travel some more to get to the actually desired destination.

I just put Linux Mint 17.1 MATE 64-bit on a Lenovo IdeaPad S415. Everything just worked out of the box, and that includes both the multitouch touchpad and the touchscreen. Also the network, wifi, sound, and graphics. Everything.

http://notebookplanet.blogspot.com/2013/12/lenovo-ideapad-s415-specs.html

That IdeaPad is a year old. A year ago, no Linux that I tried worked out of the box with it; graphics didn't work. X always got confused by the fact that the machine has two graphics adapters (one built-in to the AMD APU chip, and a discrete one).

I've really been enjoying Linux Mint 17.1; it seems to be a big improvement over Linux Mint 16. You can easily and non-destructively try it, just by booting from a USB flash drive that has Linux Mint on it. (You can use UNetBootIn to make the USB flash drive.)

While I can't guarantee that Linux Mint 17.1 will work on your hardware, it worked great on mine so I think it's worth your time to try it out.