The OpenBSD folk treat pretty much every bug as a
security hole.
Unfortunately, that wasn't the case this time. As detaild in the advisory
from CoreLabs, in fact, the OpenBSD folk refused to term this as
anything but a denial of service issue and issued the patch as a
"reliability fix" instead of a "security fix". This was done even
after Core had provided proof-of-concept exploit code to the
OpenBSD team. It wasn't until several days later that the proper
categorization was done.
Now, maybe Core is spinning things innappropriately. And maybe the
OpenBSD folks will want to correct the record. But right now, this
doesn't look good at all...
I was under the impression that CF cards, which present a traditional 512 byte block interface at the hardware level, automatically hides the complexity of managing separate flash block; and in so doing automatically rotates writes so as to avoid wear. Is this not correct?
I guess a better way to ask the question is: are you sure you have a problem here at all? Have you observed wear problems with ext3 and CF hardware? My understanding is that the only meaningful file system you should be doing with CF hardware is mounting the filesystem with noatime.
One important point to remember here is that software costs at all
levels* are invariably much, much smaller than the salary costs of the
developers who use them. (With the obvious exception of software
that requires a royalty agreement instead of a single license
purchase). Changing platforms just to save a few $K on software
licenses is, frankly, shortsighted and dumb.
That said, these prices are very high to my eyes -- much higher
than I was expecting to see. Like it or not, open source products are
perceived as a value choice by the corporate world. I have to believe
that our vendors are only doing harm to the market by charging more
for their products than the equivalent proprietary products...
The strace tool just traces system calls on a user process. It isn't
really comparable to DTrace, which is essentially a scripting language
that can be hooked to any function call, anywhere in the
system, including the kernel. It's quite slick.
The closest linux equivalent is the Systemtap project, which
is based on the kprobes low
level hooking API. These aren't yet billed as ready for production
systems, but they'll get there soon enough. They look quite slick,
also.
That said, the WSJ award seems to me to be maybe a little overstated.
While Sun fanboys will shout to the heavens (with some justification,
even) that DTrace is an amazing tool with absolutely no counterpart
in the linux world, the fact remains that DTrace is at best an
incrementally amazing tool. System performance tuning is a hard task,
requiring smart developers and lots of work. System performance
tuning with DTrace is a hard task requiring smart developers and a
little less work.
System performance tuning using DTrace and a typical Solaris IT wonk
(a population that tends to correlate highly with the fanboys pushing
DTrace the hardest) is a recipe for disaster.
If you find someone telling you that DTrace is a must have tool and
indispensable to the systems developer, apply salt. But yeah, it's
pretty slick.
Tool choices are clearly an issue of personal taste. And as my tastes
clearly don't match yours, I won't be making any suggestions.
But I will say that, without exception, all the best developers I've
known in my career (yes, every single one of them) work with a text
editor and a shell window. They use GUI and web tools where needed or
useful, but their minute to minute activity is spent at the keyboard,
writing, running and reading code.
I submit that this is not a coincidence. The best developers write
their own simple tools for small problems, and the proper environment
for running simple tools is the command line. Great programmers work
in varied environments and use diverse languages and configuration
formats, where IDEs work well only within their target realm and are
pretty much useless outside of it (e.g. no PHP mode in MSVC).
The benefit you get from fancy tools is real, but it's ephemeral. It
make the typing of code (and maybe the reading of code) easier.
But it does this by simplifying and obscuring the underlying details.
Want to add a file to the project? Add it to this dialog. Need to
check something in? Click here. Never mind how it all works, and
hope that you never get tasked with doing something complicated (like
an automated check-out-build-and-package script over a secure remote
link).
By contrast, the understanding inherent in using your tools on the
lowest level provides benefits all through the development process.
These are the folks who won't think twice about writing a quick shell
script to do the remote build.
So, by all means try out the fancy tools you can. But don't skip the
part where you learn how to use the underlying tools well. Use the
GUI stuff as an aid for the tasks you do understand, not as a substitute
for what you don't.
ANY choice made in IT means some kind of lock-in. If I go all OSS I
lock myself into something else. Of course one could argue that with
OSS you can alwais "fix or change it yourself", but then again, most
companies and users do not want to do that, they want to use
functionality. By chosing OSS you lock yourself into that path, which
is effectively no different from the vendor path.
That is a rather different definition of "lock-in" than is typically
meant. Here's an example: a company has a six-year-old core
application stored in an Oracle database on rapid aging Sun hardware.
All the other applications at the company have long since been
migrated onto Linux servers and x86 hardware, except for this one.
The company wants to move the application to modern hardware. They'd
prefer to use their linux hardware, but they can't because the oracle
license is for Sun. Or they could upgrade to modern Sun hardware and
keep the existing license. Either choice is very expensive, and not
in keeping with the long term goals of the company's IT department,
which is to move to a different platform and software choice.
This is called "vendor lock in", and it's just plain not applicable to
the free software world. Application migration is always an
option with free software. Sure, if you pick, say, MySQL as the basis
for your application, then you are stuck with MySQL (the software)
until you make the effort to port it to PostgreSQL or whatever. But
you are not stuck with MySQL AB (the company) as a gating
factor in doing your own IT tasks, like needed hardware and software
upgrades.
In what way is playing a song or a video for a class in "violation of the law?"
That depends on what your copyright law says, but I can easily believe
that you would be on dodgy ground if you played the entire work when a
sample would have sufficed, for example.
Well, then I guess it's a good thing that there aren't any technological controls
on the content preventing you from making such a sample. Are
you following the context of this argument at all?
And if the teacher is distributing content in violation of the law, then that teacher should be fired.
In what way is playing a song or a video for a class in "violation of the law?" I suppose you also think that it should be illegal to read books to the class too?
Jesus Christ, I can't see how people can be so thick about this issue...
Perhaps because the issue isn't as clear-cut as you think it is. Like many people, including much of the media, you are confusing "law" with "license". One of those is inviolate, written by our elected representatives, and must be adhered to. The other is just an agreement, and can be enforced only when it doesn't conflict with the law. You need to look up "fair use" (a legal term) and read some background on this issue.
Good comments are written first [...] gramatically correct,
punctuated [...] I put comments inside practically every block [...]
after block closers. [...] I'd rather spend a few more seconds typing
up front, and save a lot of scrolling and delimiter-matching later
(not to mention reducing confusion and mistakes).
Maybe if you didn't have so many comments in the way, your functions
would be shorter and more readable and you wouldn't need to do so much
scrolling and delimeter matching. Writing short, meaningful functions
is IMHO far more important than having clear comments. It sounds to
me like you are using comments as a crutch to make up for your use of
spaghetti code.
Code gets shuffled around in different order, read by strangers, and
reread much later by yourself, often after you've changed by
experience
And if you think said modifications will preserve the comments in
their original positions and meanings, I have a bridge to sell you.
Elaborate and extensive commenting adds a failure mode to code
modifications -- even correct comments can rapidly become lies.
There's a great quote to this effect, something like: "Don't read the
comments, they lie viciously. Debug only the code." Does anyone have
the attribution?
Actually, your position is so extreme that I'm honestly not sure if
this was sarcasm or not. If so, my apologies and thanks -- I was
definitely amused.
Yes, but alas: apparently it doesn't pay as well as responding to
the second sentence of a post out of context and ignoring all the
expository text that followed it. Yes, very lucrative. Yay.
Flame on, I guess. Rah rah. Slowlaris is teh sux0rs. Thbbt.
As much as I think a Solaris-based free unix would be a good thing,
OpenSolaris just isn't there yet. Linux has long since cross the
threshold where a typical user (an enthusiast perhaps, but not a
hacker) can drop a CD into a typical desktop machine and get a
working, internet-connected workstation. OpenSolaris isn't even close
yet.
The immediate problem is a sad lack of drivers for very common
hardware that Sun has never shipped, like wireless networking (an
Atheros driver just went into their tree a few weeks back; I believe
that's the only one so far), ACPI power management, etc... Solaris
has always been an OS for servers and managed workstations, so there
are big holes in the coverage for "consumer" devices and laptop
hardware.
Note that Sun itself has no "OpenSolaris" distribution you can
download, only a source tree. The void has been filled heretofore by
hand-cooked distros like SchilliX and BeleniX, which are roughly
analagous to early linux distros like SLS and Slackware -- no (or
minimal) package management, no exhaustive software selection,
etc... Just a bare machine with a userspace into which you can compile
your own stuff.
Nexenta looks promising, being an attempt to port the Debian
(i.e. GNU, not Solaris) userspace onto the OpenSolaris kernel. I
haven't tried it so I'll withhold judgement. But honestly, it's got a
long way to go. Note that the existing linux desktops tend to rely on
the hotplug/udev/hal/dbus architecture for much of their hardware
interface, and none of this exists on Solaris to my knowlege. Someone
will have to port it.
Honestly, at the moment OpenSolaris advocates would be better advised
to spend time writing drivers and packaging a distro than submitting
flame wars to slashdot. The world has lots of space for another free
unix, but it needs to catch up before puffing about itself as "Linux
killer".
Re:Cedega will never get my money.
on
Cedega 5.0 Released
·
· Score: 2, Informative
Eventually some change to stack sizes or libc
interfaces is going to effectively kill off your proprietary
games. Cedega will be able to run the Windows versions of the games
better than Linux will be able to run the Linxu versions of the
games.:-/
You're FUDing. Stop it. There has been one (1) incompatible change
to glibc in the last ten (10) years. If you look, you'll probably
discover that your distro still ships the older libc.so.5 library.
And the kernel interfaces (the external ones, which your games use)
have been more stable still. I'm not aware of any commonly-used
syscall whose calling conventions have changed incompatibly, ever.
Backwards binary compatibility is very important to the kernel people.
More generally, programs linked on machines running truly ancient
distros continue to run fine on modern ones provided you install the
appropriate compatibility packages.
It seems to me like you're just whining about progress. Do you have a
specific complaint about a binary on your system that no longer runs?
Having a kernel API for drivers allows developers to stay away from the mainstream kernel. This will enhance the stability of the kernel
No, no, no, no. Allowing developers to "stay away from" the kernel is
a recipe for weak testing, poor integration and random hackery ("well,
I don't know how to do this with the API but I tried this and it seems
to work..."). Being isolated, the brain damage will fester without
detection.
That statement is so far off that it occurs to me that perhaps you
were being sarcastic. In which case, your moderators should be shot.
The one thing missing from this article is the actual evidence of
abuse from the broader Open Source community.
I mean, sure, there are undeniably people who insist on running a 100%
pure free software stack (I'm close to this end of the spectrum
myself). And there are undeniably trolls out there who see the use of
non-free software (more commonly MS software specifically) as evidence
of moral corruption, idiocy, or malice. And these populations have
some overlap.
But so what? The reaction from the sane folks in the OSS community is
going to be just, well, ignorance. As a full-time linux user, I will
admit that I've never heard of "DotNetNuke" and have no plans on using
it. It just doesn't enter my field of view, sorry.
Ignoring projects isn't the same thing as "disrespect", and I suspect
the author has confused the two.
You can easily give this a reality-check: How many EU
countries have tried to use trade embargoes, tariffs or full-scale
military invasion to change the US's position on economic or political
issues? And how many times has the US done the same?
Bans on GM foods count, certainly (trying to change US agricultural
regulation via a trade embargo). There was a rash of law suits a few
years back dealing with the use of traditional "pseudo-brand" names
like "Parmesian [cheese]" etc... And of course Europe is the world
leader (well, with Japan) in protectionist farm subsidies.
The world is a complicated place. To argue that the USA protects its
interests via gaming the international trade system is of course
correct. To argue that Europe does not is just dumb.
I will grant you, though, that Europe has not staged a full scale
military invasion of the USA in almost 200 years. The USA has invaded
Europe (admittedly: with the express goal of changing its political
structure) more recently; although I kinda thought most of you guys
were OK with how that turned out...
Okay the GeForce Scheme makes sense. They just stopped
calling them Geforce 1, 2, 3...The first number is obviously your
generation number.
The Geforce scheme makes sense from the 5x00 series onward. Before,
it was a mess. The Geforce 2 was not really a generation, it was a
speed bump and rebranding of the original Geforce 256 architecture.
Geforce 3 was a new architecture (although it actually
premiered in the XBox first). But the Geforce 4 was not: in fact
cards of both the original (NV10) and second (NV20) generation
were sold under the "Geforce 4" brand.
It was a mess, especially since the differences between the two
chips was significant: the NV10 had a fixed function pipeline, whereas
the NV20 was starting to exhibit programmable "shader" technology and
was much more capable.
This is a very common misconception. Diesel fuel is denser than
gasoline. When you correct for mileage per fuel mass or (even better)
per carbon output, much of their advantage on paper fades.
Diesel engines are still slightly more efficient than typical gasoline
engines, owing to the higher compression ratios used by the Diesel
ignition process. The higher combustion temperatures, however,
produce nitrogen oxides, which are a local pollutant. And of course a
poorly tuned Diesel (or, often, just a cold one) generates a ton of
particulate ("soot") emissions -- another local pollutant.
And remember that Diesels idle very inefficiently (they have bigger
and heavier pistons, and a finicky ignition mechanism that can't be
run as lean as gasoline), whereas a hybird will shut down the engine
and idle with no emissions whatsoever (well, minus battery drain due
to the air conditioner, etc...).
The best general advice that I've read is that a Diesel makes the best
environmental choice for a long-haul vehicle that rarely idles, or for
rural areas with little sensitivity to local pollution. They make
rather poorer choices in the urban commute environment.
Disclaimer: I love my Prius, and it just smells better than the
Diesels cars I've known.
SELinux does not make anything more secure. [...]
OpenBSD has a policy that security must be on by default, must not
create a significant performance hit, and must be simple enough that
people actually use it.
Um, the SE linux configuration shipped with Fedora is on by
default, does not create a significant performance hit, and is simple
enough that most users (those who aren't making fundamental changes to
the installed daemon processes, basically) don't even know it's turned
on.
This is mostly a defensive flame. SELinux clearly is useful
as a security tool. It provides MAC features that you simply can't
get with traditional unix security model. Now, clearly, this kind of
change in worldview brings complexity. And lots of installations,
even secure ones, don't necessarily need it or want it. And early
Fedora (FC2 prereleases, I think) implementations were far too
restrictive, and cause much confusion and flamage. I have it turned
off on my laptop, for example.
But to baldly claim that "SELinks does not make anything more
secure" is just silly.
You don't seem to be responding to me. I wrote: "use whatever tools you want (and be sure to try
whatever tools you haven't)". You interpreted something rather different. If you like your tools, and have tried the ones you don't, then I salute you. We agree.
The point was that this discussion is silly. You can't get anything but a flameware from an ask slashdot post about the "ultimate setup", because there is no such thing. Flaming about emacs vs. MSVC (which I did not, but you managed to work into the reply anyway) is precicely what I'm talking about here.
Software far better and more innovative than anything you will ever
create was written by smelly geeks in university basements, on
terminals that made funny noises and worked at 9600 baud, without
source control, and with text editors that didn't have the memory
budget to implement "undo". (Which just might be the impetus that
caused them to *invent* stuff like this.)
As nice as it might be to have that "Professional Software Engineer"
title on your business card, programming is, has been, and will always
remain a task for the brain. Throwing toys at it doesn't work, it
just makes the toy manufacturers richer. Put your butt in whatever
feels good, and use whatever tools you want (and be sure to try
whatever tools you haven't). It won't make your code any better, but
maybe you'll smell nicer than the geeks in the basements.
Better, but still imprecise. The Mach kernel isn't actually a full
kernel. It's a super-kernel on top of a traditional Unix kernel. For
testing, the Mach research project used the BSD 4.3 and 4.4 kernels as
the basis for the Mach code.
Precise, but wrong. You have it backwards. Mach is a
message-passing microkernel, written from scratch that runs directly
on top of the hardware. For compatibility reasons, and to have a
usable OS to show off that uses it, the CMU group wrote a BSD 4.2
"personality" that runs on top of the microkernel. As I understand
it, this contained big chunks of the BSD kernel code, and all of its
userspace.
It was this software (the microkernel and BSD personality) that NeXT
used as the basis for NeXTStep which begat OpenStep which begat OS X,
which re-incorporated (a 10+ year re-synchronization from a different
branch?) the userspace from FreeBSD.
If a malicious process is spawned from an infected one, it's
confined to the user-space. In Linux, a kernel thread doesn't
have a distinct address space relative to any other kernel
threads.
This is just plain incorrect. You have been misinformed. (And who modded that up? Shame on you.)
Both OS X and Linux threads share the parent thread's address space
in exactly the same way. Both OS X and Linux subprocesses (malicious
or not) are denied access to the parent process's address space
in exactly the same way. There are no meaningful security
implications between these two architectures.
The sole difference between the models is the issue of
scheduling (when threads get to run, and when they must give up the
CPU): under Linux, all threads are scheduled preemptively by the
kernel. OS X uses a more complicated model where M user-visible
threads are mapped onto N kernel threads; the idea being to limit the
number of "expensive" kernel threads while preserving the benefit of
preemptive scheduling. (Except that in practice, such systems end up
introducing more overhead than they save.)
The OS X thread model is a performance optimization (or, in this
case, bug). It is not, and never has been, a security decision.
Mac OS X adds an extra layer of communication for threading,
so you can have user-space threads. [...] In Linux, everything is
a kernel thread. [...] OS X's design choice makes for more secure
communication between user-space threads and the kernel, which
gives an advantage in the workstation-space, since you can keep a
user process from running amok in the kernel.
This sounds very authoritative. But it makes no sense. What
do threading models have to do with security? What does it mean
for a thread to "run amok in the kernel", and how would I do that
if I wanted to?
I think what you're trying to say is that Apple's M:N
threading model prevents user-space threads from wasting kernel
resources, which is a common argument. But since the benchmarks
(lmbench, at least -- ignore the flawed MySQL stuff) show that
the kernel is significantly slower, the argument just
falls down. You can't argue that it's OK to waste resources to
prevent the waste of resources when the clear numbers show a net
loss. The M:N complexity gets you nothing but overhead.
A large number of organizations (as well as Debian Stable and
Redhat) still use 2.4.
This isn't correct. The most recent Red Hat Enterprise Linux
release (6 months old) is using the 2.6 kernel, and of course the
Fedora releases have been shipping 2.6 since shortly after it was
released. Debian Stable (released June 6th) ships with the
choice of 2.4.27 or 2.6.8, and of course many users have been
using the unstable distribution under the 2.6 kernel for the past
several years.
Slashdot Mirror
Unfortunately, that wasn't the case this time. As detaild in the advisory from CoreLabs, in fact, the OpenBSD folk refused to term this as anything but a denial of service issue and issued the patch as a "reliability fix" instead of a "security fix". This was done even after Core had provided proof-of-concept exploit code to the OpenBSD team. It wasn't until several days later that the proper categorization was done.
Now, maybe Core is spinning things innappropriately. And maybe the OpenBSD folks will want to correct the record. But right now, this doesn't look good at all...
Yeah, and you even get windows viruses thrown in, free!
I was under the impression that CF cards, which present a traditional 512 byte block interface at the hardware level, automatically hides the complexity of managing separate flash block; and in so doing automatically rotates writes so as to avoid wear. Is this not correct?
I guess a better way to ask the question is: are you sure you have a problem here at all? Have you observed wear problems with ext3 and CF hardware? My understanding is that the only meaningful file system you should be doing with CF hardware is mounting the filesystem with noatime.
One important point to remember here is that software costs at all levels* are invariably much, much smaller than the salary costs of the developers who use them. (With the obvious exception of software that requires a royalty agreement instead of a single license purchase). Changing platforms just to save a few $K on software licenses is, frankly, shortsighted and dumb.
That said, these prices are very high to my eyes -- much higher than I was expecting to see. Like it or not, open source products are perceived as a value choice by the corporate world. I have to believe that our vendors are only doing harm to the market by charging more for their products than the equivalent proprietary products...
The closest linux equivalent is the Systemtap project, which is based on the kprobes low level hooking API. These aren't yet billed as ready for production systems, but they'll get there soon enough. They look quite slick, also.
That said, the WSJ award seems to me to be maybe a little overstated. While Sun fanboys will shout to the heavens (with some justification, even) that DTrace is an amazing tool with absolutely no counterpart in the linux world, the fact remains that DTrace is at best an incrementally amazing tool. System performance tuning is a hard task, requiring smart developers and lots of work. System performance tuning with DTrace is a hard task requiring smart developers and a little less work.
System performance tuning using DTrace and a typical Solaris IT wonk (a population that tends to correlate highly with the fanboys pushing DTrace the hardest) is a recipe for disaster.
If you find someone telling you that DTrace is a must have tool and indispensable to the systems developer, apply salt. But yeah, it's pretty slick.
Tool choices are clearly an issue of personal taste. And as my tastes clearly don't match yours, I won't be making any suggestions.
But I will say that, without exception, all the best developers I've known in my career (yes, every single one of them) work with a text editor and a shell window. They use GUI and web tools where needed or useful, but their minute to minute activity is spent at the keyboard, writing, running and reading code.
I submit that this is not a coincidence. The best developers write their own simple tools for small problems, and the proper environment for running simple tools is the command line. Great programmers work in varied environments and use diverse languages and configuration formats, where IDEs work well only within their target realm and are pretty much useless outside of it (e.g. no PHP mode in MSVC).
The benefit you get from fancy tools is real, but it's ephemeral. It make the typing of code (and maybe the reading of code) easier. But it does this by simplifying and obscuring the underlying details. Want to add a file to the project? Add it to this dialog. Need to check something in? Click here. Never mind how it all works, and hope that you never get tasked with doing something complicated (like an automated check-out-build-and-package script over a secure remote link).
By contrast, the understanding inherent in using your tools on the lowest level provides benefits all through the development process. These are the folks who won't think twice about writing a quick shell script to do the remote build.
So, by all means try out the fancy tools you can. But don't skip the part where you learn how to use the underlying tools well. Use the GUI stuff as an aid for the tasks you do understand, not as a substitute for what you don't.
That is a rather different definition of "lock-in" than is typically meant. Here's an example: a company has a six-year-old core application stored in an Oracle database on rapid aging Sun hardware. All the other applications at the company have long since been migrated onto Linux servers and x86 hardware, except for this one.
The company wants to move the application to modern hardware. They'd prefer to use their linux hardware, but they can't because the oracle license is for Sun. Or they could upgrade to modern Sun hardware and keep the existing license. Either choice is very expensive, and not in keeping with the long term goals of the company's IT department, which is to move to a different platform and software choice.
This is called "vendor lock in", and it's just plain not applicable to the free software world. Application migration is always an option with free software. Sure, if you pick, say, MySQL as the basis for your application, then you are stuck with MySQL (the software) until you make the effort to port it to PostgreSQL or whatever. But you are not stuck with MySQL AB (the company) as a gating factor in doing your own IT tasks, like needed hardware and software upgrades.
There's a great quote to this effect, something like: "Don't read the comments, they lie viciously. Debug only the code." Does anyone have the attribution?
Actually, your position is so extreme that I'm honestly not sure if this was sarcasm or not. If so, my apologies and thanks -- I was definitely amused.
Yes, but alas: apparently it doesn't pay as well as responding to the second sentence of a post out of context and ignoring all the expository text that followed it. Yes, very lucrative. Yay.
Flame on, I guess. Rah rah. Slowlaris is teh sux0rs. Thbbt.
The immediate problem is a sad lack of drivers for very common hardware that Sun has never shipped, like wireless networking (an Atheros driver just went into their tree a few weeks back; I believe that's the only one so far), ACPI power management, etc... Solaris has always been an OS for servers and managed workstations, so there are big holes in the coverage for "consumer" devices and laptop hardware.
Note that Sun itself has no "OpenSolaris" distribution you can download, only a source tree. The void has been filled heretofore by hand-cooked distros like SchilliX and BeleniX, which are roughly analagous to early linux distros like SLS and Slackware -- no (or minimal) package management, no exhaustive software selection, etc... Just a bare machine with a userspace into which you can compile your own stuff.
Nexenta looks promising, being an attempt to port the Debian (i.e. GNU, not Solaris) userspace onto the OpenSolaris kernel. I haven't tried it so I'll withhold judgement. But honestly, it's got a long way to go. Note that the existing linux desktops tend to rely on the hotplug/udev/hal/dbus architecture for much of their hardware interface, and none of this exists on Solaris to my knowlege. Someone will have to port it.
Honestly, at the moment OpenSolaris advocates would be better advised to spend time writing drivers and packaging a distro than submitting flame wars to slashdot. The world has lots of space for another free unix, but it needs to catch up before puffing about itself as "Linux killer".
You're FUDing. Stop it. There has been one (1) incompatible change to glibc in the last ten (10) years. If you look, you'll probably discover that your distro still ships the older libc.so.5 library. And the kernel interfaces (the external ones, which your games use) have been more stable still. I'm not aware of any commonly-used syscall whose calling conventions have changed incompatibly, ever. Backwards binary compatibility is very important to the kernel people.
More generally, programs linked on machines running truly ancient distros continue to run fine on modern ones provided you install the appropriate compatibility packages.
It seems to me like you're just whining about progress. Do you have a specific complaint about a binary on your system that no longer runs?
That statement is so far off that it occurs to me that perhaps you were being sarcastic. In which case, your moderators should be shot.
I mean, sure, there are undeniably people who insist on running a 100% pure free software stack (I'm close to this end of the spectrum myself). And there are undeniably trolls out there who see the use of non-free software (more commonly MS software specifically) as evidence of moral corruption, idiocy, or malice. And these populations have some overlap.
But so what? The reaction from the sane folks in the OSS community is going to be just, well, ignorance. As a full-time linux user, I will admit that I've never heard of "DotNetNuke" and have no plans on using it. It just doesn't enter my field of view, sorry.
Ignoring projects isn't the same thing as "disrespect", and I suspect the author has confused the two.
Bans on GM foods count, certainly (trying to change US agricultural regulation via a trade embargo). There was a rash of law suits a few years back dealing with the use of traditional "pseudo-brand" names like "Parmesian [cheese]" etc... And of course Europe is the world leader (well, with Japan) in protectionist farm subsidies.
The world is a complicated place. To argue that the USA protects its interests via gaming the international trade system is of course correct. To argue that Europe does not is just dumb.
I will grant you, though, that Europe has not staged a full scale military invasion of the USA in almost 200 years. The USA has invaded Europe (admittedly: with the express goal of changing its political structure) more recently; although I kinda thought most of you guys were OK with how that turned out...
The Geforce scheme makes sense from the 5x00 series onward. Before, it was a mess. The Geforce 2 was not really a generation, it was a speed bump and rebranding of the original Geforce 256 architecture. Geforce 3 was a new architecture (although it actually premiered in the XBox first). But the Geforce 4 was not: in fact cards of both the original (NV10) and second (NV20) generation were sold under the "Geforce 4" brand.
It was a mess, especially since the differences between the two chips was significant: the NV10 had a fixed function pipeline, whereas the NV20 was starting to exhibit programmable "shader" technology and was much more capable.
This is a very common misconception. Diesel fuel is denser than gasoline. When you correct for mileage per fuel mass or (even better) per carbon output, much of their advantage on paper fades.
Diesel engines are still slightly more efficient than typical gasoline engines, owing to the higher compression ratios used by the Diesel ignition process. The higher combustion temperatures, however, produce nitrogen oxides, which are a local pollutant. And of course a poorly tuned Diesel (or, often, just a cold one) generates a ton of particulate ("soot") emissions -- another local pollutant.
And remember that Diesels idle very inefficiently (they have bigger and heavier pistons, and a finicky ignition mechanism that can't be run as lean as gasoline), whereas a hybird will shut down the engine and idle with no emissions whatsoever (well, minus battery drain due to the air conditioner, etc...).
The best general advice that I've read is that a Diesel makes the best environmental choice for a long-haul vehicle that rarely idles, or for rural areas with little sensitivity to local pollution. They make rather poorer choices in the urban commute environment.
Disclaimer: I love my Prius, and it just smells better than the Diesels cars I've known.
Um, the SE linux configuration shipped with Fedora is on by default, does not create a significant performance hit, and is simple enough that most users (those who aren't making fundamental changes to the installed daemon processes, basically) don't even know it's turned on.
This is mostly a defensive flame. SELinux clearly is useful as a security tool. It provides MAC features that you simply can't get with traditional unix security model. Now, clearly, this kind of change in worldview brings complexity. And lots of installations, even secure ones, don't necessarily need it or want it. And early Fedora (FC2 prereleases, I think) implementations were far too restrictive, and cause much confusion and flamage. I have it turned off on my laptop, for example.
But to baldly claim that "SELinks does not make anything more secure" is just silly.
The point was that this discussion is silly. You can't get anything but a flameware from an ask slashdot post about the "ultimate setup", because there is no such thing. Flaming about emacs vs. MSVC (which I did not, but you managed to work into the reply anyway) is precicely what I'm talking about here.
Software far better and more innovative than anything you will ever create was written by smelly geeks in university basements, on terminals that made funny noises and worked at 9600 baud, without source control, and with text editors that didn't have the memory budget to implement "undo". (Which just might be the impetus that caused them to *invent* stuff like this.)
As nice as it might be to have that "Professional Software Engineer" title on your business card, programming is, has been, and will always remain a task for the brain. Throwing toys at it doesn't work, it just makes the toy manufacturers richer. Put your butt in whatever feels good, and use whatever tools you want (and be sure to try whatever tools you haven't). It won't make your code any better, but maybe you'll smell nicer than the geeks in the basements.
Precise, but wrong. You have it backwards. Mach is a message-passing microkernel, written from scratch that runs directly on top of the hardware. For compatibility reasons, and to have a usable OS to show off that uses it, the CMU group wrote a BSD 4.2 "personality" that runs on top of the microkernel. As I understand it, this contained big chunks of the BSD kernel code, and all of its userspace.
It was this software (the microkernel and BSD personality) that NeXT used as the basis for NeXTStep which begat OpenStep which begat OS X, which re-incorporated (a 10+ year re-synchronization from a different branch?) the userspace from FreeBSD.
This is just plain incorrect. You have been misinformed. (And who modded that up? Shame on you.)
Both OS X and Linux threads share the parent thread's address space in exactly the same way. Both OS X and Linux subprocesses (malicious or not) are denied access to the parent process's address space in exactly the same way. There are no meaningful security implications between these two architectures.
The sole difference between the models is the issue of scheduling (when threads get to run, and when they must give up the CPU): under Linux, all threads are scheduled preemptively by the kernel. OS X uses a more complicated model where M user-visible threads are mapped onto N kernel threads; the idea being to limit the number of "expensive" kernel threads while preserving the benefit of preemptive scheduling. (Except that in practice, such systems end up introducing more overhead than they save.)
The OS X thread model is a performance optimization (or, in this case, bug). It is not, and never has been, a security decision.
This sounds very authoritative. But it makes no sense. What do threading models have to do with security? What does it mean for a thread to "run amok in the kernel", and how would I do that if I wanted to?
I think what you're trying to say is that Apple's M:N threading model prevents user-space threads from wasting kernel resources, which is a common argument. But since the benchmarks (lmbench, at least -- ignore the flawed MySQL stuff) show that the kernel is significantly slower, the argument just falls down. You can't argue that it's OK to waste resources to prevent the waste of resources when the clear numbers show a net loss. The M:N complexity gets you nothing but overhead.
This isn't correct. The most recent Red Hat Enterprise Linux release (6 months old) is using the 2.6 kernel, and of course the Fedora releases have been shipping 2.6 since shortly after it was released. Debian Stable (released June 6th) ships with the choice of 2.4.27 or 2.6.8, and of course many users have been using the unstable distribution under the 2.6 kernel for the past several years.