Follow Slashdot stories on Twitter


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

Comment Nimble? (Score 2) 161

"Nimble" does not mean that it performs well.

If "mainstream productivity" refers to word processing and web browsing, you are fine. But if you're doing photo, video, audio editing, heavy software compilation, scientific simulation or other work, fast boot times are not what you're after. Gaming, too, why not CPU-heavy usually, demands GPUs that only high-end, very expensive laptops can deliver.

Yes, laptops keep getting better, but so do workstations. For the same money, you get much more bang from a desktop as compared to a laptop.

The real story is how well the bottom has reached decent levels for "mainstream productivity." 5 years ago, a $200 netbook was really disappointing in terms of everyday performance: web browsing was slow, video playback was choppy at higher resolutions, and even word processing could get laggy. These days, machines at that price range are totally acceptable. Entry-level laptops like the Acer E3 or the HP Stream 11 are surprisingly good. Unless you're doing "workstation" work, they won't feel any slower than a laptop that costs 10 times as much.

I think that might actually be what this article is clumsily trying to say.

Comment Multiple meanings of "monolithic" (Score 3, Insightful) 551

There is a confusion of two aspects of "monolithic" here, and unfortunately Poettering did not clarify it well:

1) "Monolithic" in terms of a single repository for all code. The systemd project is monolithic in this respect, and Poettering is absolutely correct that this is the classic Unix way. All the *BSDs are maintained this way. Linux is thus, as he correctly points out, the anomoly.

2) "Monolithic" in terms of tools that depend on each other. The systemd system is not monolithic in this respect. The only two required components are journald and udev. Everything else is entirely optional and replaceable, but "recommended" in the sense that the people working on the project really think that these components, written from scratch, are of better quality and consistency than the existing components they replace. But some hysterical people hear this recommendation as "forcing it down our throats". Distro makers will decide which components to use, whether those in the systemd project or the existing ones. Obviously, the existing ones have the benefit of maturity.

Also, he doesn't point this out in this interview, but these new components are also better at reporting errors in a way that the whole init would be more robust when certain components have partial failures (and systemd knows how to deal with them). This is especially crucial for servers with complicated, layered network stacks. People say that systemd is for desktops, but really it is just as important for servers to have a robust initialization of services.

Comment #gamergate (Score 3, Funny) 642

OK, my fellow gamergaters, it's time to dox Sweden!

She lives just east of Norway and west of Finland. Make sure to visit that feminazi every day and teach her the consequences of trying to censor all games and force us to play Depression Quest!

Together we will fight to guarantee better ethics in game journalism.

Comment Ubuntu changed everything (Score 4, Insightful) 110

Ubuntu changed everything we've come to expect about free, general-purpose operating systems.

People don't give Launchpad enough credit: for the first time, we have an integrated build/test/deploy process for the whole operating system. It takes the solid Debian root and adds a layer of modern quality assurance that we've never seen before. There's still a ways to go, and I'm sure people will complain about one or other package being broken, but the fact is that Ubuntu raised the bar of what we've come to expect.

Slashdotters and others also love to complain about one particular package or another. Obviously, the desktop environment (or just the shell) is the first thing that most people see. But it's also a small project in the larger scope of Ubuntu. Don't like Unity or GNOME 3 or KDE or Xfce or LXDE or Enlightenment? You have lots of options. Don't like systemd? Well, Ubuntu devoted a lot of time and effort to Upstart, but made the mature decision to abide by Debian's decision to go with systemd (for now). Don't like either? Yeah, well, life these days must be truly hell for poor little you.

And now, Ubuntu may do for mobile what it did for the desktop. In 10 years, I hope we can celebrate the existence of truly free devices, onto which we can install any package we want -- including alternative UIs for those who will undoubtedly not like Unity.

Comment C is better than C++ for the kernel (Score 5, Insightful) 365

Having been on the fence about this for a while, my experiences convinced me that C++ is wrong for the kernel.

The problem is not the extra features. The problem is that the programmer has little control over exactly how they are implemented: the compiler decides how to handle virtual method tables, destructors, multiple inheritence, etc. In the recent past, C compiler bugs have caused serious problems with Linux development. C++ compilation is an order of magnitude more complex, and you can bet it would be less reliable. This also means that C++ compiles much slower: doesn't sound like a big deal, but it is a cost to take into account.

The lack of a standard, clear ABI for C++ is also problematic. While it's true that Linux is monolithic, it still supports modules that interact with each other dynamically. Debugging C++ can be quite painful because of this. But it also means that it would be that much harder to contribute a module if it's not written exactly for the same compiler as the one used to build the kernel. Of course, it would have to be written in C++, too. This lack of flexibility can be quite painful in environments where you are limited to very specialized compilers (embedded). C has the most standard ABI of any language (well, C and Pascal). You can guarantee that *anything* would be able to interface with it.

So if you put the technical cons (losing control, flexibility and debugabbility) vs. the pros (cleaner syntax) then it's right to pick C, on technical grounds. As others have stated here, anything you can do in C++ you can do in plain C. It's a bit clumsier, but then you have complete control over the implementation. I do OOP in C all the time, it's perfectly OK. If anything, a bit more powerful than C++, because I tailor the OOP features to exactly my needs and tastes.

Beyond that, there is the more controversial issue of programmer culture. C++ hides away implementation details, but for kernel development you want programmers who think about every tiny issue of implementation: exactly what is going on with the call stack, what is a pointer and what isn't? The more explicit nature of C encourages a more hard-nosed stickler for technical correctness, which is more important than pretty code for kernel work.

By the way, I'm writing this as a former C++ zealot. I even created something like this in the past, a C++ wrapper for Windows NT networking services. I found out the hard way that C++ takes more than it gives. I write all my code in C these days, and don't feel like I'm missing anything.

Comment Re:Unified Experience Across Devices (Score 1) 644

Windows 8 unified tablets and desktops. You can buy a 7" Atom-based tablet right now that you can connect to a dock and get a full desktop experience.

But Windows phones are still different. With Windows 10, you will be able to the above with your phone.

That might not seem like a big deal to you, but it can radically change the computing market. For many people, owning a single computing device (a phone) will be enough. They will just get a dock for a tablet (BlackBerry has this) or for a laptop or for the living room and that's it. Enterprises, too, can invest in fewer gadgets per employee.

Today's phones are powerful enough to run most everyday computing tasks. Obviously not all, but for those people who need the power, workstations and gaming PCs will still be around.

Comment The Unix Way (Score 1) 613

It's the "Unix way" to make one tool do one thing well. The "systemctl" tool is not meant to show status.

The point in Unix is that tools are building blocks. You can create a higher-level tool (using a simple shell script) that uses these tools together to do cool things that the devs have not thought of.

Comment Re:bad for standards (Score 2) 194

This has nothing to do with the "tag" itself, which does not specify codecs. Yes, this is still a compromise, but many of us have been compromising for years on various aspects of freedom and openness. Choose your battles carefully and you can win the war: Mozilla has already achieved so much for the open web, and I'm confident the upward slope will continue.

Comment Genymotion (Score 1) 167

I agree: indeed Genymotion fills in this gap perfectly, and I recommend it strongly for any Android dev. I also found Genymotion devs to be amazingly prompt in responding to bug reports. (I have no connection the company, am just a fan of their work.)

But it's still surprising the that official Google toolkit doesn't have anything like it. Google, get on board! Just buy up Genymotion or license their tech.

By the way, emulation still has its uses in some cases... it's of course best to have both.

Comment Short Intro (Score 5, Informative) 272

It's a mistake to think that "NoSQL" is a silver bullet for scalability. You can scale just fine using MySQL (FlockDB) or Postresgl if you know what you're doing. On the other, if you don't know what you're doing, NoSQL may create problems where you didn't have them.

An important advantage of NoSQL (which has its costs) is that it's schema-free. This can allow for more rapid iteration in your development cycle. It pays off to plan document structures carefully, but if you need to make changes at some point (or just want to experiment), you can handle it at the code level. You can also support older "schemas" if you plan accordingly: for example, adding a version tag or something similar that can tell your code how to handle it. So, even ignoring the dubious potential of better scalability, NoSQL can still be beneficial for your project.

More so than SQL, NoSQL database are designed for different kinds of applications, and have different strengths:

MongoDB is a really good backend engine that gives programmers lot of control over performance and its costs: if you need faster writes, you can allow for eventual integrity, or if you need faster reads, you can allow for data not being the absolute freshest. For many massive multiuser applications, not having immediately up-to-date data is a reasonable compromise. It also offers an excellent set of atomic operations, which from my experience compensate well for the lack of transactions. Furthermore, MongoDB is by far the most feature-rich of these, supporting aggregate queries and map-reduce, which again can make up for the lack of joins. It also offers good sharding tools, so if you do need to scale, you can. Again, I'll emphasize that you need a good understanding of how MongoDB works in order to properly scale. For example, map-reduce locks the database, so you don't want to rely on it too much. The bottom line is that MongoDB can offer similar features to SQL databases (though they work very differently), so it's good for first-timers.

Couchbase is very good at dispersed synchronization. For example, if parts of your database live in your clients (mobile applications come to mind), it does a terrific job at resynching itself and handling divergences. This is also "scalable," but in a quite different meaning of the term than in MongoDB.

I would also take a look at OrientDB: it's not quite as feature rich as MongoDB (and has no atomic operations), but it can work in schema-mode, and generally offers a great set of tools that can make it easy to migrate from SQL. It's query language, for example, looks a lot like SQL.

The above are all "document-oriented" databases, where you data is not opaque: the database actually does understand how your data is structured, and can allow for deep indexing and updating of your documents. Cassandra and REDIS (and Tokyo Cabinet, and BerkeleyDB) are key-value stores: much simpler databases offering fewer querying features: your data is simply a blob as far the engine is concerned. I would be less inclined to recommend them unless your use case is very specific. Where appropriate, of course simpler is better. With these kinds of databases, there are actually very few ways in which you can create an obstacle for scalability: simply because they don't do very much, from a programming perspective.

There are also in-between databases that are sometimes called "column-oriented": Google and Amazon's hosted big data services are both of this type. Your data is structured, but the structure is flat. Generally, I would prefer full-blown "document-oriented" databases, such as MongoDB and OrientDB. However, if you're using a hosted service, you might not have a choice.

It's also entirely possible to mix different kinds of databases. For example, use MongoDB for your complex data and use REDIS for a simple data store. I've even seen sophisticated deployments that very smartly archive data from one DB to another, and migrate it back again when necessary.

"The fundamental principle of science, the definition almost, is this: the sole test of the validity of any idea is experiment." -- Richard P. Feynman