The Sad State Of FSF's High Priority Projects

Quote:

---

Originally Posted by XorEaxEax

As they state, the list is a '_guide_ for volunteers and supporters to projects where their skills can be utilized' which is simply a wish-list pointing out categories in which open source alternatives are poor or non-existant. From the tone of Michael's article it's like he is trying hard to portray the lack of activity in many of the suggested projects as a failure of FSF (wish-lists are supposed to be OPTIMISTIC). As for the projects FSF actually sponsors on this list (afaik it's Gnash and Coreboot), I've only used Gnash and while it worked perfectly well on Youtube it failed to work on alot of other sites I visited. I haven't used Lightspark so I can't really say anything on that apart that from what I've heard Gnash and Lightspark currently complements eachothers weaknesses to some extent but they are still no replacement for Flash unless your needs are very limited. Personally I don't see chasing after Flash as a viable goal (and given the low developer interest both in Gnash and Lightspark I'm not alone), better to embrace html5 and free open source codecs like vp8 while using the (admittedly poor) offical Flash support if you need it.

---

+1. This place is becoming like an anti-FSF soundboard these days. Poo-poo FSF this, poo-poo FSF that. And call it "open source" while you're at it, and dilute the terminology of the FSF, and misquote them as calling certain projects "open source", and on and on.

I'm starting to think Michael is a Microsoft or Oracle shill who pretends to be a friend of the FOSS community, when in reality he just seeks to undermine and eliminate the FSF, so the ideals of freedom will go away, all FOSS code written will be licensed under BSD, and then Microsoft will happily take all the code, make it proprietary and release it as Windows 9.

I know that sounds pretty fantastic and highly unlikely, but if you'd have told me in 1990 that a major proprietary desktop operating system (OS X) was being developed based on BSD and OPENSTEP, I'd have laughed you out of the room.

It's quite a concept, isn't it? Companies wanting to eliminate the voice of Free Software so that only Open Source remains?

Companies love Open Source. Even Microsoft. They absolutely love it -- free labor! What could be better than having other people make your products for you, without even paying a dime, all in the interest of sharing? And then you're perfectly entitled to go and take their code, make it proprietary, add some gee-whiz enhancements that break compatibility but don't really contribute anything, and make billions of dollars! And you only need to hire half the developers of your fully-proprietary competitor!! It's a genius business model!

But wait, there's a huge catch. Some little subset of the Open Source movement are some kind of freedom-lovers, who want their software to remain free, and have devised a clever copyright license that prevents us from making their work proprietary. Well damn, that sucks. Let's see how we can get rid of them!

Hmm.... let's start with the media. What are some good websites out there where a lot of young people influenced by Free/Open Source go to be informed? Ah... first hit on google... Phoronix! Let's see if this... Lillybell, er, Larabel, guy is susceptible to a few greenbacks.

And on it goes...

id like to see some office stack thats up to the task, thats capable of opening, changing, saving documents, that has the same features (or more) like MSOffice programmed in a coherent and flawless way. i think with that done many people and companies would give in their Windoze setups and gladly use linux. but unless formats are being changed and pictures in docs not able to see or manipulate and there is no appropriate VisualBasic and Access replacement for alle the forms, control and navigation stuff, people will be forced to stick to windoze.

Be it OpenOffice or LibreOffice... i dont mind, but please get it to some state people using office in a daily manner will be able to use it.
Is there a replacement for outlook?

Quote:

---

Originally Posted by allquixotic

+1. This place is becoming like an anti-FSF soundboard these days. Poo-poo FSF this, poo-poo FSF that. And call it "open source" while you're at it, and dilute the terminology of the FSF, and misquote them as calling certain projects "open source", and on and on.

I'm starting to think Michael is a Microsoft or Oracle shill who pretends to be a friend of the FOSS community, when in reality he just seeks to undermine and eliminate the FSF, so the ideals of freedom will go away, all FOSS code written will be licensed under BSD, and then Microsoft will happily take all the code, make it proprietary and release it as Windows 9.

I know that sounds pretty fantastic and highly unlikely, but if you'd have told me in 1990 that a major proprietary desktop operating system (OS X) was being developed based on BSD and OPENSTEP, I'd have laughed you out of the room.

---

I think that you're going too strong here; there is no harm in questionning about fsf high priority projects and money usage.

Quote:

---

Originally Posted by XorEaxEax

Extremely unlikely, as I recall Stallman himself said he made a huge mistake in going with mach (he hoped it would save development time, lol). It seems very few developers are interested in the hurd, and like with so many other interesting alternatives out there such as Haiku, Reactos, Aros etc there's zero commercial sponsoring interest. Sadly.

---

There is a better ReactOS called Windows 7.
Haiku is cool, but only for x86 desktop usage.
Aros? Never heared about it.

They don't offer anything revolutionary. It must be technologically very advanced. ReactOS and Haiku... are not by design. They have a different interest.

The reason Mach is causing so much pain, is because Mach isn't fully satisfying HURD's design goals. HURD was already going away from Mach, but the developper of the Mach-replacer is burried in RL work, so work on Mach continued. But that's not a problem, because HURD is portable. Once work resumes on the other microkernel, all Mach work can be ported with a layer. So development research can continue on Mach as an interim solution.

Ofcourse releasing HURD half-assed is possible, but everyone would pull a *yawm* and stick with another *nix OS. So it must be great, without compromise.

Aside from popular believe, HURD is still going strong. Advancements are still made, but it must be considdered a research OS for now.

Quote:

---

Lowest level access support while abstracting hardware? Hard to reconcile those terms is it not? Anyway, not really my area but doesn't OpenCL offer something like this?

---

We're talking IR code that doesn't change. OpenCL is not realy like that. OpenCL is basically C running on the CPU and dropping GPU bombs (called kernels) for computing, but those bombs need to return. So what we need is a along the lines of:
-Small API returning banks and one-time best performance return values that a program can work with (dynamically changing parallel workloads, like with Rage for example)
-Some IR language for saying "Perform this, lookup that" without layers, based on performance values returned by the API, and chewed by (for example) a Galliumisch driver. However, there must be direct memory management access. Nothing must be abstracted if it isn't strictly needed.

Quote:

---

Unlike FSF/Stallman I see nothing inherently bad with proprietary code, but even so it's pathetic to equate such ideas with 'religion'.

---

The OS must be approached as the OS itself, not as a resistance thing "FLOSS makes you enlightened" and all that stuff. The OS must sell itself, not its philosophy.

Quote:

---

Originally Posted by V!NCENT

There is a better ReactOS called Windows 7.
Haiku is cool, but only for x86 desktop usage.
Aros? Never heared about it.

They don't offer anything revolutionary. It must be technologically very advanced. ReactOS and Haiku... are not by design. They have a different interest.

---

Revolution is cool and stuff but first and foremost you have to have something that WORKS and be able to deliver. Linux works, Haiku is in Alpha. HURD is NOT ready.

until its ready they can hopefully dedicate some resources in helping mesa which is something we need NOW.

Quote:

---

Originally Posted by cynyr

Excel: We need a replacement for excel that supports macros, and loading COM dlls. I'd be happy to be able to easily pack some python code (with modules) into a openoffice file. I don't need VBA compatibility, but to be honest VBA is likely easily converted to python automatically well enough.

---

Gawd... Let's please NOT do that. Companies that treat Excel like it's a real development front-end, and Access like it's a real database server eventually find themselves in a bad place when they spontaneously implode, I've seen it happen. Spreadsheets have their place, but applications should be developed as applications, scripts should be scripts, and data should be kept on a real database server.

Thanks for helping to shine a light on the GNU project and the Free Software Foundation... I hope there are many more stories on this topic going forward. These high priority projects are important to ensure that people have the a free software desktop option which serves a majority of the needs and goals people have for their computer, and it's good to have a debate regarding whether or not certain items should really be on this list (and if others should be added). Just having this discussion increases the visibility of this important organization and its goals, which is nothing but positive in my book. More people need to be aware of these ideas and the work that is being done to ensure free software remains so and is being improved constantly... and that they can help.

My main interest at the moment is with GNU/Hurd. As mentioned previously, this project is very interesting in that it has the lofty goal of being based on a microkernel architecture, while at the same time being microkernel agnostic where possible. There have been several microkernels which have been the basis of GNU/Hurd over the years, and the work with each of them has served to increase the experience and knowledge base for the GNU developers while ensuring that the Hurd benefits from the best implementations in whatever way possible. The gnumach microkernel is the one which has ended up having the most adoption and focus up to this point, but work continues with other microkernels to some extent. There are definite issues with gnumach, but these issues aren't considered to be an insurmountable hurdle for the Hurd project itself... in fact the Hurd will see it's first major release on the upcoming Debian version with the gnumach microkernel (see also ArchHurd for another quickly developing Hurd-based distribution).

The Hurd promises many interesting capabilities which are just not possible with a monolithic kernel design, and these possibilities are evident to any user of the system. Imagine navigating various types of remote file systems, databases, code repositories, etc. all as if they were just files on your local system? Using tar, cp, vi/emacs, on these files in the same way as you do with local files is possible due to the user-space Hurd translators which serve as wrappers which make this possible.

Another interesting possibility is that various parts of the Hurd can be written in other programming languages, which has both benefits and drawbacks. But this possibility makes it that much easier for the various code bases to be used for features of the operating system which weren't possible with other systems.

One of the roadblocks many new architectures face to adoption is the lack of driver support. With the Hurd this will be much less of a problem due to the fact that many Linux drivers will eventually work without modification and without a slowdown in performance. Currently most Linux 2.0 drivers work, and DDE is functioning to some extent at this time (which opens the possibility for Linux 2.6+ drivers to work in the same way).

The last point is the benefit of the Linux kernel development to the Hurd. Due to license compatibility, some of the work that has gone into the Linux kernel can be re-used in the Hurd where it makes sense. This is one of the benefits of GPL code, and also one of the benefits of supporting the GNU project and the Free Software Foundation. Unlike many other projects based on other licenses, the GPL does the most to guarantee the code developers produce not only is free to use in whatever way desire, but that it remains so for current as well as future users. This is the area where I see people have the most confusion when it comes to the differences between various licenses, as well as between free software and open source.

Quote:

---

Originally Posted by babali

I think that you're going too strong here; there is no harm in questionning about fsf high priority projects and money usage.

---

I think he's talking overall. One time Phoronix posted some troll's article about how Linux will succeed with bsd license. That troll was an os x fanboy. Phoronix doesn't know what FLOSS is. They don't even know what are they benchmarking sometimes and then they spread misleading informations.

Quote:

---

Originally Posted by 89c51

Revolution is cool and stuff but first and foremost you have to have something that WORKS and be able to deliver. Linux works, Haiku is in Alpha. HURD is NOT ready.

until its ready they can hopefully dedicate some resources in helping mesa which is something we need NOW.

---

Exactly. I don't know what drives some people to look at crap like hurd or haiku when there's Linux. I'm sure when the hurd matures (just kidding) they'll start looking at something else in the name of something. Hurd is not only unready, but it will be SLOW.

Quote:

---

Originally Posted by joshuapurcell

The Hurd promises many interesting capabilities which are just not possible with a monolithic kernel design, and these possibilities are evident to any user of the system. Imagine navigating various types of remote file systems, databases, code repositories, etc. all as if they were just files on your local system? Using tar, cp, vi/emacs, on these files in the same way as you do with local files is possible due to the user-space Hurd translators which serve as wrappers which make this possible.

---

You mean like fuse allows on Linux? That is the thing I don't understand about all this "microkernel" stuff. Linux already has support for userspace drivers of several types. If someone really wants userspace drivers, why can't they just code better support for that in the Linux kernel like people have already done for some systems? So rather than just dumping a well-supported and heavily-tested kernel for an entire new one, you slowly migrate (where appropriate) to a more userspace-level design. This seems to be a much more efficient approach.

Quote:

---

Originally Posted by joshuapurcell

Another interesting possibility is that various parts of the Hurd can be written in other programming languages, which has both benefits and drawbacks. But this possibility makes it that much easier for the various code bases to be used for features of the operating system which weren't possible with other systems.

---

You mean like the various fuse bindings?