Recent Comments

I think I remember when the position changed on this. A load of people in England had been complaining due to not having the technology because the English team lost out a couple of times because of it. Then in one game they benefit from the lack of goal line technology and the official position is reversed to now want goal line technology. Some were joking it was just because England benefited for a change that the stance changed.

This is the most recent of several astronomy/space exploration posts that has received very few comments. Hope we can find a few to join us - I find this stuff fascinating!

I thought this was obvious but I'll say it for the record. If this or most any site is to succeed, the vast majority of readers will be anonymous lurkers. They won't be futzing with settings or themes, even if some settings were available to people without logins.

The defaults matter, a LOT. They are all that most people will EVER see of your site. This is a huge problem for Soylent by the way -- their default presentation is still bloody awful -- but much less so here. Other than the icon/photo thing, Pipedot's defaults have all been very smartly chosen.

Huh? Why would a properly written GUI admin interface be any less capable of importing and acting on your new user file than your script would be? Why would a GUI admin interface, for that matter, be incapable of itself being scripted to customize actions for the administrator?

You're describing scripting or programming a task, something that is not the exclusive domain of a terminal session or bash shell. Windows itself has a few methods of scripting, though they can suck. I've used VBS scripts for exactly the user creation process you describe.

Absolutely, stuff runs faster and more efficiently without the GUI overhead, and once one is comfortable with one's scripting environment of choice one can program things fairly well. But some things, like selecting a specific set of names (or files) from a long list and selectively moving them to a new OU (or directory) are a royal pain by command line and trivial in a GUI. Conceptualizing and managing something like an LDAP structure is far easier and more accurate in a GUI.

There are pros and cons to both interfaces. The problem, again, is that Linux doesn't even offer you the choice.

I wonder what the price will be in 10 years. http://www.bitcoin-pizza.com

I could just hire a sort of Cato to jump out and give me a fright every so often:

The scientists were able to show that following high-intensity exercise, which enlists the sympathetic nervous system's "fight or flight" response, CRTC2 integrates signals from two different pathways-the adrenaline pathway and the calcium pathway, to direct muscle adaptation and growth only in the contracting muscle.

Lazily awaiting science's creation of an exercise pill that will activate this protein for me.

Settings -> Story Image Style -> Icon :)

I find the need is just as strong in Windows to dive for the command line. There are quite a few tasks if you're administering an active directory network that really can't be done in the Windows GUI.

The real problem with Windows is it *still* doesn't have a native ssh daemon in 2014 and the only effective way to administer a particular server is through a graphical rdp connection.

I'm not sure what all the hate for Gnome 3 was about. I've used Debian for quite a long time, and when Debian 7 came out it shipped with gnome3 as the default desktop. It took me all of half an hour to get used to and it seems to work well and doesn't get in my way. Granted, being a Debian user meant I missed out on perhaps any early horrors Gnome 3 had, but to be honest I find it a very competent desktop and have felt no desire to go back to a Gnome 2 like interface (in fact I always make sure the 3D drivers are working so I get a proper Gnome 3 desktop if I set up a new machine).

Ha ha, I was thinking the same thing - for this story at least, my kingdom for an icon!!!

I fully agree. GUI and servers have nothing to do with each other. I am all for GUI "control panels" for the normal home user, as Linux will not succeed if the normal user is not able to change some settings in their own computers.

As a server administrator I would hate GUI for servers. Instead I use a combination of scripting, salt-stack and direct ssh contact. Lets take this trivial case: In the fall when the schools begin, I end up creating user accounts for every single new student. I receive name lists. Those list I format into the way I want (sed/vim). Then I run the lists trough a script I made which will create random password, make their home directories and set up everything right for them. Out I get a csv file containing their usernames and passwords. That csv file I can use in any office application. How do you do that efficiently by GUI?

It is not a coincidence PowerShell appeared in Windows. Any administrator not able to script is pretty much a worthless administrator. A such person is wasting time (=money) by doing over and over the same task. Mistakes will creep in here and there as with any repeated task.

Another case: Lets say a service has hung. Now I am able even with my phone and a simple ssh client to take remote connection and restart the service. As soon you have GUI and VNC/RDP/Whatever GUI you need more bandwith and working over a slow mobile connection might be almost impossible. Take then screen size also into account.

"Just twenty one minutes of exercise a week? Hey doc, that almost sounds too good to be true."

It is the picture of Michael Conkright, PhD, the TSRI assistant professor who led the study of the article in question. At least it's more relevant than the broken window stock photo from a few stories back.

...and here we see a problem with thumbnailing a picture from the article for the story icon--when there is only one picture.

And I'll be the contrary bastard who liked Eli best of the lot. He's the only one I wholly trust.

And I'd be very pleased if there was more SG:U as well as whatever new SG comes along.

...before they start showing up at the Olympics??

At least he seems happy. Must be the exercise.

There's no real reason a Linux mail server should be an order of magnitude more difficult to administer than an Exchange server

Job security.

More seriously, the GUI takes a non-trival amount of overhead to run, and those of us who can't afford new shiny hardware appreciate that. The vast majority of Linux sysadmins I know are more comfortable in a terminal anyway. Plus, the Linux approach gives you some more flexibility. I'd much rather have a steeper leaning curve than to be stuck to The Exchange Way.

I appreciate your thoughts, but I turned to WebMin/VirtualMin precisely because I don't spend enough time in Linux to be completely comfortable managing every server application at the terminal, even though I am otherwise aware of general administrative needs and procedures. The hope was that it would help me manage Postfix, sendmail, LDAP, user management, various webmail daemons, Apache, SpamAssassin, WordPress, SSL Certificate management, etc., without having to remember or cheat sheet everything. To an extent it does that, but very imperfectly. Without it, there's a huge nut to crack, as evidenced by a ridiculously long primer on setting up a personal mail server that Ars Technica recently featured.

There's no real reason a Linux mail server should be an order of magnitude more difficult to administer than an Exchange server. But without VirtualMin or something like it, it is. (There's a damn good reason that CPanel gets away with charging as much as it does.)

I don't particularly care if I lose massive geek points saying it and trying to rely on the server side tools, but I'm quite sure there are others like me who are otherwise competent but don't yet have the shell wizardry to go bareback.

Again, thanks for the feedback.

Wow, I was kind of with you, until you suggusted servers should have guis.

I mean, maybe your right about moderate tech users not being able to do everything on a desktop via gui. I would suggust they were better off learning bash & related tools if they are going to call themselves moderately technical.

BUT NO GUIS ON SERVERS!!!!

My god phatphil, and nice real identity by the way, are you really so dimwitted that you think everyone sees icons by default? We don't, you slow witted cretin, which is why I asked what the devil you were blathering on about. With as lightly trafficked a site as this, a reasonably savvy and moderately intelligent human would address things actually visible. You are clearly neither savvy nor minimally intelligent nor even courteous. You're a bloviating fool in rightful obscurity muttering to himself about the unfortunate shape of the clouds in the sky. Enjoy this tiny bit of attention; it's more than you deserve you ungraceful twat.

They are dismantling the sleeping middle class. More and more people are becoming poor. We are their cattle. We are being bred for slavery.

They are dismantling the sleeping middle class. More and more people are becoming poor. We are their cattle. We are being bred for slavery.

They are dismantling the sleeping middle class. More and more people are becoming poor. We are their cattle. We are being bred for slavery.

The problem with APIs is that for each API one can make cross platform wrapper, and its works damn well
Even DirectX which was microsoft flagship api to lock the users like you say can be wrapped, and some games do this.

On the other hand, an language, locks you very hard to vendor's platform. For instance if your code is in C# your only hope is Mono and with that your
code probably be always of 2nd citizen quality on non MS platforms which is what MS wants.

About Go, I think you are right, chances are that is was really created as a research project at least without initial goal of vendor lock-in, something also evident from the fact that they did LInux, Mac, Windows, and even FreeBSD releases of their compiler.

But swift... I could only imagine how badly its entangled with Apple libraries...

The big vendors lock app developers into their platform via APIs and services. The role of the programming language is really secondary. Really, I think Apple and Google are innovating here, not in a large sense (as Java was back in the '90s, or C++ in the '80s) but incrementally improving on current practice, which is what they should be doing.

Thank you for the reference. FF just updated itself somehow to v29 in the background which showed when the computer was rebooted. Urg. FF29 interface is horrible.

Meanwhile, I am giving Pale Moon a try.

Its two words: vendor lock-in.
Having your own language that is only available on your platform and has tons of legacy software written in it is the wet dream of all these corporations.
Thats why we are still stuck in the world of C/C++, as its the only compiled language that is guaranteed to be cross platform, and doesn't suck completely, (but still sure sucks).

Interesting argument but I think you miss the most important subtext of my position -- that the NIH approach robs us of the power of collaboration and the power of standards. Whether or not the companies making the new language go through the motions of positioning them as standards, people typically react as if they're proprietary islands -- 'cause they are.

If Apple were really interested in improving the state of the art, they'd contribute great ideas and code to improve an existing language or create a new one in collaboration with many others. But "hey here's our new language" is the same as "you must buy your software from our App Store TM". It's part of locking things down and limiting progress.

Since the major browsers use something other than SSL it's not a big deal as far as browser security no. Some utilities (can) use Openssl like wget, and anything secured using stunnel is vulnerable. My only worry is patching my mail servers, some of which talk to each other using TLS only and assume the connection is secure.

Ok, the Catching Fire bluray finally reached the top of my Netflix queue and now I have to take back most of what I said about Hunger Games. I still think the first movie sucked (they are fighting the wrong enemy), but the 2nd movie did a decent job of recovering the series. I might even go see the 3rd movie while it's recent. :)

If I understand correctly, this only applies to OpenSSL client to OpenSSL server communication, NOT browser to OpenSSL server (?).

So while huge for those who relied on it this way, the pool of vulnerability is smaller than Heartbleed.

... upgrading

ii libgnutls26 2.8.6-1+squeeze3 the GNU TLS library - runtime library

I'm talking about the *icon*. You're confusing the photo with the icon. This should be clear from the fact that you used the term "photo/icon". Look at your settings for the image preferences and re-evaluate what you wrote.

Then stop starting sentences with "Uh".

Eventually, you may be coherent enough to be able to post under a real identity without bringing shame upon yourself. But that might be years away, you have a long way to go.

Thanks for that. The list of affected packages is small, the list of affected systems...quite something else really.

While perhaps this is just NIH syndrome, I think we *need* new programming languages to replace the ones we already have. And especially new languages that can replace C.

I largely agree with the C/Python language stack. But C isn't by any means perfect and I feel that some things could really benefit from some re-thinking. C is good, but if thousands and millions of hours are being spent coding in it, even small improvements are worth a lot. Objective-C seemed to me like a good thing, except for being limited to apple-products, because adding classes to C is both simple and powerful. For this reason I've been telling myself I need to check out D for some time. C has a great theme, and I doubt I'll give it up for some time, but I admantly believe people can do better.

And lets not forget ADA, a language that as far as I can tell has never seen its equal. It may not always be what you want, but the sheer power of compile-time checking in that language is amazingly useful. Honestly I think a language like this really needs to come back for coding mission-critical software. Oh how many failures could have been prevented if only people used a tool like ADA! Unfortunately, ADA just isn't as useful as other languages atm, for sheer lack of library and community support.

In short, when programming languages are being used so widely and when so much time is being spent using them, it is completely unreasonable to *not* look for improvements. Improvements in performance (though at the moment that isn't as much of an issue), improvements in error checking and robustness, and improvements in ease of use for faster development time. Even small improvements in any of these can be so valuable. With that in mind, does it really seem so strange that companies on the cutting edge would look to take advantage of their position to try to improve their own abillity to develop programs?

Uh, the summary photo/icon is the same velociraptor robot. What are you talking about?

rubbing one off for freedom

Exim (mail server) and CUPS (print server) are on the list.

https://en.wikipedia.org/wiki/Linux_Standard_Base

It's existed for 13 years. No one seems to have cared.

Yes, I know that sounds like BS from a bygone day, but as a mostly-Windows geek, every time I dive deeper into Linux, on desktop or server, I'm struck by the eventual need to go to the command line / terminal.

That's okay, for me -- I LIKE the command line and spend a fair amount of time there in Windows -- but reports to the contrary I don't see a way for a moderately technical user to avoid it under Linux. Far too many things are still VERY much dependent upon it, from daemons to drivers to fixes to patches to scheduling to startup etc. When something really goes wrong, you know the answer will not lie anywhere in the realm of the available GUI.

Sure, theoretically a user can steer apt-get or yum shells via a GUI, and can open up config files when necessary in a GUI editor, but who are we kidding? There's just no way you can live entirely in the GUI in Linux as you can in Windows, for technical or (to a lesser degree) non-technical users.

On the server side of course it's FAR worse. Using something like WebMin one inevitably ends up resorting to the command line fairly often.

Sure, every OS is just a thin veneer over what's going on underneath, and GUIs more so, but that surface is still too thin and shatterable in Linux distributions and desktops. My favorite desktop is KDE, and many distros shun it!

I quite agree with your suggestion that this is, potentially, more about NIH syndrome rather than a necessary change... which does not preclude that it is going to turn out to be a useful evolution in coding...

My hypothesis for why every big company might make such moves at some stage -- if they can -- is the temptation of control. If you support standards, common tools, etc., then people might build things that you haven't anticipated in ways that you might not be able to mediate and so on. I think the business case for control and lock-in seems obvious to many, but I also think people try to create "the foundation" for all other activities based on their personal outlook. I have seen spouses, bosses, children, etc. try and exert "their way of doing things" on everyone around them simply because "their way makes the most sense". To move in the other direction, i.e., to facilitate many different people's outlook or activities pseudo-equally, a given person or business must be able to value the cognitive dissonance that can arise when other people want to arrange or do things on their own terms... just a thought (and probably not well formed).

I'm not sure I understand why we need to keep inventing new things. What's wrong with existing tools?

For speed and control over everything, including bare metal, I'll use C. For everything else, I'll be lazy and use Python. Others may choose different tools, but I suspect the end result is the same, finding an adequate tool for the job, and using it. Not reinventing the wheel just because.

Why is every successful company so enamored of the smell of its farts that it has to invent its own programming language? Google did it, Apple's doing it; back in olden times there were flavors and branding but Fortran was more or less Fortran, COBOL (blargh) was COBOL, PL/1, etc., etc.

If code is code, and interoperability speeds progress for everyone, what's with pervasive Not Invented Here syndrome?

It ends up leaving us all relying on lowest common denominator CRAPOLA like JavaScript.

Objective C was cool with its late binding and everything, but it was not fast. I had an app that took advantage of the cooler parts of Objective C, only to have apple silently disable that feature without warning.

I for one found Objective C to be an enormous headache--not that it matters anymore since I'm no longer using anything Apple, but, well, good for someone?

R.I.P. Macintosh.

Unfortunately, making one unified decision is not really possible for a collection of community projects. I would love to see a set of standards built that distros could conform to, so you could test against that standard instead of a distro, but I can't see that happening anytime soon.

Having used commercial software on Linux in the manufacturing sector, support is usually only provided for a few main distros anyway (Debian, Red Hat and SuSE in my case). If you can get the binary to run on another distro, then that's great, but you are not going to get anything close to the same level of support as the officially sanctioned distros. For most applications I actually don't see that as a major problem, although RMS would certainly have something to say about the restriction of choice; it's still Linux, and in a commercial setting you are probably choosing the best OS/distro for your required apps anyway, rather than the other way around.<br><br>

Another problem was the issue of libraries, particularly when they were more obscure on one distro but bundled with another. A poke around in the dependencies for the various packages revealled that the typical solution here was either to statically link any such libraries across the board, or in a few cases to do so selectively from distro to distro, dynamically linking to the distro provided versions where available and statically linking the rest. Worst case scenario would be to just statically link the entire lot, which is an approach I've seen used for several Linux games - commercial or otherwise.<br><br>

So, it's not as if the problems don't have solutions, although they are not necessarily ideal, which leave me thinking it's more to do with the low return on the time and effort required. Unless you are working off the back of one of the major Linux desktop migrations that pop-up from time to time and making the binaries available to all, you have a much smaller userbase, split across multiple distros that are potentially different enough to be treated like different OSs from a compilation and support perspective. Each distro you support gets you more users, but adds to the cost of developing, compiling and testing the code, plus supporting it when you are done, and for many apps, particularly the more complication ones the numbers almost certainly just don't add up. So perhaps the real question is "what can the Linux community do to make the numbers add up?"

Some random twitter personality claims there was a secret predetermined warrent cannary, which was activated recently. But its so super secret that only a few people are in the know, and they can't tell us what it was for reasons unexplainable. Eithere they're afraid of a rubber hose style differential cryptoanalysis, or they need to have their medication levels checked.

As someone that has been using Linux about 15+ years, I see the biggest problems like this:

Giving up OSS sound system.
Other *NIX system still uses OSS in one way or another and many programs are able to output sound. First Linux went all Alsa and you had many problems with cracking sound. Playing sound from many sources was nearly impossible so you had to use Arts, Esd etc (Yes, arts and esd was also needed at the time of OSS, but some development could have got rid of that dependency as *BSD did). All the drivers had to be rewritten. To complicate things even more they decided to slap Pu-pu-ppu-ppul-puls audio system to the already broken architecture. OSS was all about what UNIX should be: working with files (simple and elegant). Even to this date, when a Linux user wants Skype to work properly I might have to fight a lot getting the sound to work properly. Many times a growing noise appears which do not appear with other OS.

Broken desktops.
Early we had two competing desktop systems: KDE and Gnome (because of license issue). Every single time I tried Gnome, I had terrible crashes also it was quite sluggish. Opening a folder with pictures took forever as the thumbnails were created each time. It was also lagging terrible behind KDE in many other ways. Still it was the first choice in many distors meaning a new user got a really bad taste of Linux. KDE was still usable, but there was a small chance your distro was running KDE as default.

Then came KDE4 which completely destroyed the only really powerful and usable desktop at that time. Gnome had grown up at that time to be somehow usable. But Gnome also decided to mess up their desktop, which resulted into many new broken desktops got created (Unity, for example).

Now we still have some usable DE like Xfce, but they are still lagging behind what we have and they are not impressing on users coming from other OS.

Many more factors.
I do not intend to write a long article so I just conclude here that there are many more factors preventing Linux to be used in every computer.

Has anyone told Randall about this, over at XKCD?