LWN: Comments on "New GNU Hurd, Mach, and MIG releases"

New GNU Hurd, Mach, and MIG releases

Cyberax — 2013-10-02T01:00:26+00:00

PHP programs are in general far more secure than C-based ones. However, PHP itself is horrible for web development.

New GNU Hurd, Mach, and MIG releases

wahern — 2013-10-01T23:45:56+00:00

I meant, "that Java programs have fewer security bugs (i.e. are 'safer') than C programs".

New GNU Hurd, Mach, and MIG releases

wahern — 2013-10-01T23:44:45+00:00

How do you go from describing the origin of bugs in Java-the-language-implementation to arguing that Java programs have fewer bugs than C programs?

PHP is "safer" than C in the same regards. Would you also argue that PHP programs tend to be safer and have fewer bugs than C programs?

I'm not at all sure that Java programs tend to be safer than C programs in 2013. Buffer overflows and stack smashing are pre-eminent in the C world precisely because many other classes of exploitable bugs are less prevalent, for many different reasons--engineer experience, typical usages, etc. C also tends to get more CVE reports precisely because historically has predominated in large, widely used programs that are under the microscope.

I'm not saying that Java programs are less secure. Maybe they're more secure. But the type of memory corruption possible with C is but one factor, and the potential for the same kind of corruption exists in all languages when executed on commodity hardware. And advances in mitigation techniques has narrowed the gap substantially in terms of the susceptibility to exploitable memory corruption.

New GNU Hurd, Mach, and MIG releases

marcH — 2013-10-01T22:15:31+00:00

"I once heard that Hypervisors are the living proof of Operating System's incompetence."

http://linuxconeurope2012.sched.org/event/bf1a2818e908e3a...

Micro kernels, virtualization, zones, containers,... we are all spoilt with choice.

New GNU Hurd, Mach, and MIG releases

HelloWorld — 2013-10-01T21:52:47+00:00

Most of Java's security issues are related either to unsafe code called via JNI or to JVM bugs concerning malicious class files. The first class of bugs of course also applies to C programs since C doesn't even try to be memory-safe. The second class of bugs is irrelevant for a kernel, because if you have the right to load code into the kernel the system is compromised anyway. So yes, Java programs are a lot more secure than C programs, occasional bugs notwithstanding.

New GNU Hurd, Mach, and MIG releases

nix — 2013-10-01T16:47:32+00:00

I think the problem with microkernels is that nowadays the same benefits can be achieved with memory-safe programming languages.

That was, I believe, the hyped-up promise of the Java security model. It doesn't really seem to have worked all that well...

New GNU Hurd, Mach, and MIG releases

drag — 2013-10-01T14:12:52+00:00

It would be nice.

New GNU Hurd, Mach, and MIG releases

HelloWorld — 2013-10-01T09:10:08+00:00

I think the problem with microkernels is that nowadays the same benefits can be achieved with memory-safe programming languages. I think that Rust, which incidentally had its 0.8 release just a few days ago, is a prime candidate for this kind of programming.

New GNU Hurd, Mach, and MIG releases

Cyberax — 2013-09-30T22:29:24+00:00

Looks like we're experiencing the second iteration of microkernels with hypervisors and guest OSes..

New GNU Hurd, Mach, and MIG releases

drag — 2013-09-30T20:57:52+00:00

Everybody is 'users' to somebody else. It just depends on the audience you are focusing on. If you are writing low-level system libraries then the 'users' are the application developers that chose to depend on your library.

What is needed to move beyond 'nitch hobbyist' to solve a unique problem or solve a problem in a superior way to a existing solution and then convincing people that their lives will be easier if they use it.

So far 'Microkernels' have been long on promises, short on results. Promises of security and stability improvements have never materialized while performance and scalability remains a perennial problem. Hence why so far they remain hobbyist toys. I think that even at this point the academics have moved on.

New GNU Hurd, Mach, and MIG releases

Kluge — 2013-09-30T15:57:01+00:00

>But one can be both a microkernel enthusiast and a Hurd enthusiast.

Sure. My point was that as there are a number of FOSS monolithic kernels out there, anyone preferring to work on HURD will be a microkernel enthusiast. But HURD isn't the only FOSS microkernel-based OS out there, so there is presumably competition for those developers.

New GNU Hurd, Mach, and MIG releases

rsidd — 2013-09-30T06:42:23+00:00

Well, Hurd runs on top of a microkernel (Mach) and had been ported to L4. Apparently that didn't work out. But one can be both a microkernel enthusiast and a Hurd enthusiast.

New GNU Hurd, Mach, and MIG releases

Kluge — 2013-09-30T04:58:21+00:00

Expectations are certainly one hurdle. The other is probably competition. MINIX3 and L4 are also out there, presumably competing for a limited number of microkernel enthusiasts.

New GNU Hurd, Mach, and MIG releases

rgmoore — 2013-09-29T20:26:55+00:00

I don't think user-facing software is the critical part. It needs a group of developers who are intending to use it for serious, real-world applications. Those applications can be user-facing, server based, embedded, or whatever, but they have to be something people depend on. Having users who depend on it will give a committed developer base. Without that, it's just a hobbyist system that has people working on it because it's cool, and they'll be tempted to jump to something else that appears cooler.

New GNU Hurd, Mach, and MIG releases

khim — 2013-09-29T17:31:44+00:00

The big problem for HURD are changes in expectations. HURD 0.5 (and probably even HURD 0.2) is significantly more capable then, e.g. Linux 1.0.0. But over last two decades expectations of developers and users have changed. Today HURD is not not something someone will want to actually use.

New GNU Hurd, Mach, and MIG releases

mpr22 — 2013-09-29T15:19:44+00:00

Not merely "developers", but "people who will develop user-facing software that people who are not ultra-niche computer enthusiasts care about"

New GNU Hurd, Mach, and MIG releases

rsidd — 2013-09-29T15:12:11+00:00

Developers are users too. It needs to have a minimal level of usability, as well as offer a minimal level of excitement, to attract developers. I don't know whether it does but the record so far isn't good.

New GNU Hurd, Mach, and MIG releases

el_presidente — 2013-09-28T21:15:05+00:00

Developers, developers, developers, developers.

They are the people that matter at this point in time.

New GNU Hurd, Mach, and MIG releases

rgmoore — 2013-09-28T19:32:37+00:00

A lot of people are going to take a new look at Hurd now that there is a new release.

Only relative to the number who were looking at it before. In an absolute sense, the number of people who will look at it will be a statistical blip compared to any of the BSDs, much less GNU/Linux. Compared to the really popular systems like Windows or Android, it will be well below statistical noise.

New GNU Hurd, Mach, and MIG releases

cesarb — 2013-09-28T14:51:25+00:00

> Or use git, nowadays.

Not enough. Uninvolved bystanders are not going to follow each git commit a project makes. They want a somewhat stable checkpoint to look at, be it tarballs or git tags (which can also count as a release).

Until this announcement, for uninvolved bystanders the current release of Hurd was 0.2. Not some random version control commit.

A lot of people are going to take a new look at Hurd now that there is a new release.

New GNU Hurd, Mach, and MIG releases

mbanck — 2013-09-28T13:04:57+00:00

> Release early, release often!

Or use git, nowadays.

Ironically, apparently one of the factors on why new releases have been made just now is GUIX' (http://www.gnu.org/software/guix/) policy of only using tarball releases for their packaging (well, and I guess the 30th birthday of GNU was a nice occasion as well).

New GNU Hurd, Mach, and MIG releases

nix — 2013-09-28T12:42:45+00:00

Release early, release often! (And from a wider historical perspective, compared with, say, the rise and fall of empires, they are.)