SoylentNews is people
SoylentNews
According to an email sent to the Debian debian-devel-announce mailing list by Adam D. Barratt, the Debian GNU/kFreeBSD port is in grave danger of being dropped from the upcoming Debian 8 "Jessie" release. Debian GNU/kFreeBSD runs the GNU userland tools, the GNU C library and the Debian package set on top of the FreeBSD kernel.
Barratt states:
We remain gravely concerned about the viability of this port. Despite the reduced scope, we feel that the port is not currently of sufficient quality to feature as a fully supported release architecture in Jessie.
We therefore advise the kFreeBSD porters that the port is in danger of being dropped from Jessie, and invite any porters who are able to commit to working on the port in the long term to make themselves known *now*.
We will assess the viability of kFreeBSD in Jessie on or after 1st November, and a yes/no decision will be taken at that time.
(Score: 3, Informative) by TheRaven on Wednesday October 08 2014, @08:45AM
XFree86? Not really dead, as X.org is a fork and no one worked on the original after the fork, so it's more a rename than anything else.
Firefox? Really? I use it on Android all the time. They're under pressure from Chromium to implement a proper sandboxing mechanism though, so I don't know how long they'll last.
GNOME? Possibly, I haven't used it for over five years so I've no idea what the current state is. MdI seemed intent on copying every bad idea from Microsoft and ignoring any good ones.
Perl? Maybe not as widely used as before, but cpan is still full of actively developed things. There's now competition from Python, Ruby, Lua and so on, so it's no longer a case that every problem has to be solved with C or Perl, but I don't see that having more options is bad.
GCC? Well, the license is annoying and we're now seeing the exactly how much harm the open source ecosystem suffered from GCC's refusal to put in clean layering. While GCC is still slightly beating clang on optimisation (I reluctantly admit, as an LLVM developer), LLVM is used in pretty much every other language and embedded in the graphics stack. I saw my framerate for XBMC with no GPU acceleration jump from 3fps to 30fps when I switched from the old MESA code to the LLVM softpipe driver. We could have had that kind of improvement 20 years ago if GCC had been released under a license that allowed incorporation in X drivers and with sensible layering that made such adaptation possible. Most GPU drivers are also using LLVM for optimisation, so we're now seeing the real benefits of open source: code reuse in places the original designers didn't imagine. LLVM started life as a new optimisation framework for GCC (and was offered to the FSF, who rejected it), but now it's most widely used to JIT compile shader languages (including RenderScript on Android). Even a quickly written LLVM-based JIT typically gives a speedup of 5-10 times over a well-written interpreter (30+ over a badly written interpreter).
Debian? So what, it's a distribution. They aggregate the work of others. There will always be more people willing to do that.
sudo mod me up
(Score: 2) by VLM on Wednesday October 08 2014, @12:10PM
"MdI seemed intent on copying every bad idea from Microsoft and ignoring any good ones. "
Sounds like a creeping featuritis init system thats been widely discussed lately.
I tell ya, EEE embrace extend extinguish is whats going on. After EEE gets far enough, some submarine patent is going to surface and its bye bye linux hello marketing FUD for the competitor. SCO 2.0
(Score: 2) by mtrycz on Wednesday October 08 2014, @01:16PM
You seem to be forgetting that it's not an init system, but a base OS. It does contain an init system, logically, but it's certainly not limited to one, neither in practice nor by design.
In capitalist America, ads view YOU!
(Score: 0) by Anonymous Coward on Wednesday October 08 2014, @04:15PM
I disagree in that ...
... but I fully agree with that.
Indeed, I'd argue that by making the code intentionally hard to dissect and adapt, Stallman has effectively made gcc less free, as in less supporting of the four software freedoms he himself stated; more exactly, of the following freedom:
"The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1)."
The design of gcc means that you are actively hindered from learning how the program works, and from changing it to do your computing as you wish. This was done explicitly from the the fear that someone would use those freedoms in order to circumvent them.
Yes, you can do all those things with the source of gcc (and there are certainly people who did). But then, you also can do all those things from a normal executable, by disassembling it. It's just yet again more work.
Lesson: When trying to protect freedom, be careful not to damage it by the very measures you're trying to protect it with.