OSNews

Moreover: no modular micro kernel

I thought that discussion was over with in 1991!

May be SEL4 you are interested in !!!
http://ertos.nicta.com.au/research/sel4/

Comment score, at the time at which I read this : 11.

Epic win.

Comment score, at the time at which I read this : 11.

Epic win. "

I wonder what happens once it reaches 40 O.o

It will have a nonzero probability of reaching 42

At the time I saw it (just now) it was at 49, the same as the number of comments here. Coincidence? Only if you consider that I'm comment #50 and before commenting I took the score to 50.

Sure you can reach that score. Just copy another funny comment from slashdot, like the author of the parent thread did.
http://linux.slashdot.org/comments.pl?sid=2196142&cid=36285752

Not copied that I can see, at least not word for word, or really even in spirit. The comment on Slashdot had an entirely different feel to it than this one. And who knows, it could have been the same person there as here, and he just carried his own joke over in a different format.

Besides, there has to be more than one person who thought of a joke like that. We're not all twenty-something newbies who only know XP and beyond, you know.

Of course, I could be completely wrong, but who cares? If it was funny to you, laugh and go on.

To be honest if they make such as simple mistake as a version check, I don't really want that software on my system. Just sayin'

How do you know that software you do currently want on your system doesn't contain latent errors? You might not actually want the software you want

Write better scripts. It's not Linus job to make sure crappy scripts doesn't work.

Kernel development is definately important and this kernel continues to have a faster development cycle than the other mainstream OS kernels. (70 days or some such thing on average?) Personally, I could do with seeing more support from hardware manufacturers in getting drivers into the main line instead of being aftermarket binary blobs or third party reverse engineering projects for lack of manufacturer support.

In terms of news though, I think an Xorg update would be a much bigger anouncement. Everything is going toward touchscreen devices yet that area of support in Xorg and Gnome/KDE remains a big gaping pile of missing. Consider the Asus Eee PC touchscreen all-in-one:

- easy to config touchscreen support. Just install xserver-xorg-input-evtouch, update your xorg config (it doesn't autodetect is said to be the new Xorg way), reboot and whammo.. your Eee PC touchscreen working hapily. - nope.

- easy to config touchscreen support. Just grab the interface manufacturer's provided driver, run the setup script and reboot. - nada. No Va.

To the manufacturer's credit, they do provide Debian5 and Ubuntu 10.04 native drivers among four or so other OS. They just don't actually work (if Nvidia can deliver a GPU driver that works across multiple OS distributions, a simple input device can't be that hard to do).

I'd really like to see touchscreen support and auto-config improved in the graphic layer with finger-poke interfaces being the hot selling feature these days.

Secondary question:

Anyone have suggestions on desktop sized touchscreens that behave well with Linux based OS (preferably Debian)? I've been banging my head against this lack of support for a while now. It remains the one outstanding issue that keeps me from moving on to more interesting home projects.

I'd rather see something about Wayland in that case.

Well, you'll certainly see a lot about wayland from 2012 onwards, as that is clearly where Linux is headed now.

The one thing I'll miss or have to replicate is support for GUI forwarding over SSH and it'll need Nvidia GPU support before I go anywhere near it but given those two requirnments, I wouldn't complain if it shipps with a future Debian.

If a Wayland requirement breaks NX, then all 150 of my users will be moving to Windows. That's not a threat. It would probably happen over my dead body. And we could move to some distro that supports X. But if Wayland is the future of Linux, Linux will eventually be my customers' past.

We care about getting work done, and network transparency. VNC-like "solutions" are a total joke for real work.

Wayland advocates care about shiny eye-candy effects to amuse them. If I presented Wayland's "advantages" to my customers, they'd laugh me out of the room. But they like me. So they'd probably chip in to send me to a good sanitarium.

-Steve

Deployments such as yours will probably be running X server as a wayland client, and the X clients (i.e. apps themselves) will use X11 versions of the libraries to work in network transparent fashion.

That said, it will probably be a long time before RHEL & likes move over. Wayland is important for mobile and desktop, but somewhat uninteresting to enterprise. I.e. MeeGo and Ubuntu will jump first.

New KDE Project Aims at Tablets, Mixed UIs

http://www.osnews.com/story/24634/New_KDE_Project_Aims_at_Tablets_M...

http://www.techworld.com.au/article/382938/new_kde_project_aims_tab...

http://community.kde.org/Plasma/Active

http://community.kde.org/Plasma/Active/Contour

I grant you it is a new project. They do however already have a a proof-of-concept working on certain hardware, with a basic working shell, but an incomplete set of key applications.

Cheers. I'll have to watch how this one progresses. It's a bit heavy for my current project but well worth considering should touch screens become a normal function in laptops (or I have the disposable budget to put into a proper Toughbook again).

At present, I'm trying to get simple touch support. I'm basically booting a minimal install through XFCE into a browser. If I can get it working, I may actually boot raw Xorg into the browser with no window manager inbetween though it causes some issue with any popup windows. The idea is to dedicate one of my machines to a pure touchscreen thinclient.

I remember compiling Linux 2.4.0 for the first time. It has improved multi media support which was going to revolutionize the Linux desktop.

That's the problem I have with Semantic Versioning. If a product only adds feature, and fixes bugs, in an API compatible way all the time... the said product is supposed to be at 1.x.x for ever? Say... 1.1024.42?

perhaps now he did it so he can start the version numbering to approach Pi... like TeX.

What do you mean with massive breaking API changes? Care to elaborate?

Breaking the binary system call interface, in the case of Linux. Like, I don't know, giving a new parameter to malloc that is mandatory and has no default value. Or switching the integer type used to store PIDs from 32-bit to 64-bit, it that's not done already.

Edited 2011-05-30 14:55 UTC

Isn't that just bad programming on the developer's part?

Not necessarily so. In the case of the PID example, 32-bit PIDs may have served well for decades and saved boatloads of RAM before a day came where Linux was used on clusters so large and running so much processes that the ability to run more than 4 billion processes at once became needed.

That's why people should use libc and use the ANSI C and Single UNIX Specification standards. If you use syscalls you ought to get bitten in the tail.

By the way, the kernel does not have a malloc system call, it is implemented as a C library function. The C library normally manages the heap, and grows the heap if necessary with the brk() (or depending on the implementation/situation mmap()) system call.

Edited 2011-05-30 16:33 UTC

or generally speaking some massive breakthrough such as an architecture overhaul, a whole host of new features or a complete ui rethinking in the case of an application)
ABI changes needn't happen... remember that early versions of NT were based on a (Mach- like) microkernel, but even migrating whole subsystems from userspace services into the kernel executive, didn't result in a mass breake of userspace applications - API/ABI breakage involved platform libraries in charge of direct interfacing with the migrated (reimplemented) system services - but applications linked to them, could continue working unchanged (as long as those libraries were accordingly reimplemented)

Agree, I think linux should keep the old numbers until braking API and/or really large underlying changes.

To you perhaps, but not to everyone subscribes to that view. Some prefer not to give an particular meaning to "major" and "minor" version numbers other than, well, it's a new version.

I've always preferred to bump the major version for ANY change in features, no matter the size or scope, and the minor version if only bug-fixes were done. That's perhaps the most common form of version number handling I've seen among the programmers I associate with. But to each their own... I just find it silly that a "mature" product with more than a decade of work can still be at version 0.xxx.

Major version releases for products like Linux Kernel is just a silly notion. Going from 2.8 to 3.0 seems just as logical then any.

Too much common sense for one post there, friend.

Which number should be replaced with a date? The major, the minor, the patch number or the additional backport version number?

So one date for 2.x.x, one for 2.6.x, one date for 2.6.40, and one date for 2.6.40.x patches?

I think numbers over 40 are annoying is as good a reason as any, just like, date? what date? multiple dates are annoying..

The problem is Linux version branches now. When 2.6.32 is released, it is finished from Linus point-of-view but it is still maintained has bug-fixes backported etc. Hopefully this will become 3.x is released by linus and 3.x.x are released by point-release maintainers with bug-fixes only.

Edited 2011-05-30 13:37 UTC

The problem is that atleast in Linux kernel the version number DOES indeed mean something. In x.y.z versioning if z changes it just tells you that it's a bugfix and any modules compiled against the previous version should work just fine on newer versions too. If y changes then it means that release has some new functionality, drivers and/or features that are remarkable enough to warrant version bump. It might also break something, but usually shouldn't. If x changes then it is a major devision from previous versions and most likely breaks any and all out-of-kernel-sources modules.

This is important for example for compatibility reasons. With date-based versioning you'd lose all that, you couldn't for example deduct whether your driver will work on current release if the driver was made 5 releases back.

So there IS indeed a meaning to those version numbers. Why Linus bumped to 3.0.0 then? Well, he apparently felt that the kernel has deviated so much from 2.x.x line, even with incremental changes, that it warrants a version bump.

Yeah sure, version the kernel after some guy who happens to be the excuse for some stupid religion. That would be something.

And Linus said it was time based. Third decade of kernel development.

This is what I am thinking, but I would use a two-digit year, no leading '0', and no day of the month so the version above would be 11.5.2. I do not follow Linux kernel releases so I do not know if Linus has released more than one kernel in the same month, but if he has/will then the day would be included like so, 11.5.3.2.

You did put more thought in it then I did and I like it,

two digit year.two digit month.two digit patch version, like 11.5.2 is indeed far better the mine and is more in line with current version number.

Dates are (1) meaningless, (2) arbitrary and, worst of all, (3) non-uniform.

Until we can have all months with numbers of days divisible by something sensible, like 10 or 2, and until we can have years with a number of days divisible by something sensible, like 10 or 2, and until we can have a number of months divisible by something sensible, like 10 or 2, then I say "No thanks!" to date-based versioning.

Everything has a release date anyway. Why throw out the version number?[i][/i]

I guess they should have written better build-scripts, eh?

You need to capitalize the T in "the". http://en.wikipedia.org/wiki/Capitalization

Edited 2011-05-30 18:03 UTC

Thanks. I turned off auto-capitalisation on my iPad yesterday, and apparently had no time to get used to it