you need updating all the time to stay up to the list.
Did you miss the GP's "then only update those packages on the DoD's list."?
Unless that DoD list constitutes the bulk of a Linux system (100+ packages? - TFA only mentions 4!), then you still won't be "updating all the time", so your point is?
Gentoo is great for learning how to fix things that are broken.
Even assuming this breakage happens as often as you imply (not my experience), where does it say that *you* have to fix the problem? When something fails to download/build/verify, I just wait till the devs fix it. Your current system isn't touched until the final install step, and I honestly can't remember the last time I saw the final install step fail.
config file syntax has changed subtly
Config files are normally updated at install time. For those that you want to control changes to, you use something like dispatch-conf or etc-update to review changes before allowing them, at which point you'll notice the change - if you're paying attention (if you aren't then don't blame Gentoo). Of all the kinds of breakage I see, this kind is the rarest, IMO. Most breakage is of the failed-compile variety, at which point you just mask that version of the package and wait for the fixed version.
If that option changes the semantics of the language, it's not an optimization.
The "semantics of the language" don't help us since, in this case, we were already in "Undefined Behavior" territory by the time of the ptr check.
Which I hope the compiler guys will decide, and fix it
Looks like the kernel guys have gone with one of the other options I mentioned, they are explicitly turning off that optimization option for a kernel build.
Note the last two paras in that post, and in particular: "(I think the argument that the gcc optimization is generally a bug have been sufficiently debunked, it's busted tunneling code, no ifs ands or buts)"
No, it should be in the -fthis-is-not-a-c-compiler -fyes-I-really-mean-it options -fyes-I-am-an-idiot-why-do-you-ask.
This is an utterly silly response given the complex situation of this particular error:
1) A language which allows for implementations to handle NULL differently. C doesn't have a strict clear specification for how to handle NULL derefs, or for that matter, even what NULL ultimately equates to, precisely *because* its used in so many different environments.
2) Invalid code to begin with (a ptr check after the ptr had already been used)
3) That bad code, even *with* the ptr check removed, would normally have PANICed the kernel, *except* when a linux security module was loaded that *allowed* valid memory to be mapped to addr 0, which *violated* a basic premise of GCC (and most C compilers). This point is the biggie: its extremely linux-specific, how in the hell can a cross-platform compiler (that is not linux specific) have handled this situation, or even *known* about it, never mind what the C Standard says about this, or more accurately, what it *doesn't* say?
4) an optimization option that (we now know) shouldn't have been used for the kernel (now fixed - see the post above).
Notice how it took *several* things, in sequence, to "go wrong" for this error to occur?
And point #4 is I believe the real issue: a "user" of the GCC compiler was not setting up GCC to properly handle their obviously unusual environment. The onus should be on the *user* to use the tool properly, not for the tool to just "magically know" how it should behave in wildly different environments. Indeed, how *could* it possibly know what do in this complex case? It seems from the post above, that the "user" in this case (the linux kernel), is doing exactly that: telling GCC not to do something that isn't valid for their environment (but is perfectly valid for *most* other users, e.g., the compiling of *applications*, as opposed to a complex operating system kernel).
Suggesting that we go back to more conservative compilers that don't attempt significant optimizations (which ultimately *requires* the modification and even *removal* of source code from the output) just isn't realistic at all. The world seems to be actually headed in the opposite direction: compilers that optimize even more aggressively.
The compiler assumed that if tun had been dereferenced, it couldn't be NULL.
Well, technically, the compiler assumed that since it had been given the '-fdelete-null-pointer-checks' optimization option, that that was what you wanted it to do.:)
That's a false assumption
The author's of that compiler optimization *knew* that it was a false assumption "for some environments". Read that option's description. This wasn't a bug in the typical sense, e.g., an accident or unintended behavior. The issue appears to be a little more interesting:
a) Should this option have been included by default in the -On options that it was (2/3/s)? Perhaps it should have been restricted to just -O3, where the "dangerous" optimizations supposedly live?
b) How are compiler author's to decide what opts are used for a given -On? If an optimization that is useful for, say, 90%(*) of compiler users, should it be included and on by default, or are you/others suggesting an optimization should only default to on if its valid for *all* compiler users? Who should carry the burden of taking explicit actions to keep the compiler from doing something thats not useful, or simply invalid, in their environment, the 90%, or the 10%?
c) Do the kernel devs have *some* responsibility here (aside from the mistake in the code itself)? Perhaps the kernel make should have been explicitly turning this option off, because in the kernel environment, this optimization is *not* useful? After all, if an app plays with a null pointer, just the app stops, but if the kernel does the same thing, the whole world might come crashing down.:) Those two environments obviously need to handle null pointers a bit differently...
Note: I'm not arguing for/against the kernel devs or the compiler devs, I'm just asking.
(*) I pulled the 90/10 ratio out of thin air, its just for discussion's sake. The compiler devs probably have a better idea of how broadly useful this particular option really is... or do they?:)
Thus, he couldn't test for null before initializing.
Of course he could. 'recommended style' != 'required rule'
In fact, in the very next function that follows the function with the bug in tun.c, there is an uninitialized variable being declared, and then initialized later, *after* a sanity check. In hindsight, this should have been done here too.
I'm guessing the author probably just made an honest mistake of looking at the code above:
struct tun_struct *tun = __tun_get(tfile);
and thinking that the __tun_get function, which initializes the tun pointer, wouldn't return a NULL. We now know it obviously can, so perhaps he simply forgot or misremembered that.
If the kernel were using C99, the programmer could have done his argument sanity checks first
Programmers still make mistakes when using C99 too. After all, this *is* pointer-heavy C we're talking about here.:)
Everytime I try to use Linux I always end up needing to compile the kernel
Every time? Always? Wow, such strong words, pity you don't back them up with anything.
a better tool than menuconfig/xconfig
The tool isn't the problem, IMO, its the sometimes incomplete and/or confusing descriptions of the config options which tend to trip people up. Of course, this is why all the main distros compile the kernel for you. No one ever said doing it yourself was easy (or was even supposed to be). Hell, when is doing *anything* yourself "easier" than having someone do it for you?
there is no place for me on Linux.
Actually, I'm wondering just how hard you actually tried to make a place for yourself...
I am more then a user but not a system/kernel programmer.
"system/kernel programmers" aren't the only people who compile their own kernels.
Something I would think Linux developers/distros would be very concerned about.
Why do you think all the major distros provide their users with precompiled kernels?
It's just another thing stopping Linux from more a widespread adoption.
Being able to compile the kernel yourself has absolutely nothing to do with Linux's lack of popularity, and you've made no attempt to show that anyone *has* to compile it...
idiot prepackaged environments
You do realize this description basically applies also to Windows & Mac OS, not just to all of the most popular Linux distros in use, don't you? "idiot" just doesn't make any sense here.
make your environment all by yourself
"Linux from Scratch" is the *only* "distro" that actually requires that.
through years of personal experience in system level software design/programming
Hyperbole much?
Many, many people compile the kernel on a routine basis without ever looking at the source code.
But that's how it is I guess.
That would only be true if your "it" was in any way remotely connected with reality...
Of course it doesn't help that you started off with a vague reference to "problems that require you to compile the kernel yourself", without, unfortunately, any specifics at all. You'll need to actually give a real example of this kind of "problem" before anyone can take you seriously...
Wrong. There is no requirement that FLOSS software be available at no charge. Its the source code which must be made available at no charge.
So, why would the F/OSS community trumpet this as a "win"?
Because we've had to listen to trolls, shills, and the ignorant tell us for years that "no one is going to make money selling FLOSS software", and for years we've tried to explain the difference between paying for the software (software as a monetized "product"; profit derives from the software itself) and paying for customer support to use the software (software as a commodity; profit derives from services provided with the software), but to no avail. Heck, even after all this time, we've still got trolls using "communism" in the same sentence with FLOSS.
1. People didn't pay RH $80 for the software, they paid them $80 for customer support...
2. And RH is successfully making money over the long term doing it...
3. Even though the underlying software is FLOSS.
Lines 2 & 3 above are why this is a "win" for us, not line 1.
When explanations fail, whether because they have fallen on deliberately deaf, or merely ignorant, ears, then there is nothing better than a working example... and thats exactly what RH is.
The Obama administration is the one propping up all manner of failed business models with "bailouts".
Huh? The GP's post was entitled "CIT and moral hazard". Well, CIT is NOT being bailed out, and "moral hazard" was the reason used by the Fed under the *previous* administration for NOT bailing out the second corp that got into trouble (Lehman Bros., I believe), so actually *neither* the present or the previous administrations have bailed out "all manner of failed business models".
Instead of trying to blame Bush or Obama for the whole mess, why the hell don't we deal with the real issue here, which is that a free market system which accepts the concept of "too big to fail" is NOT really a free market! We don't seem to talk about that problem as a society because we're too busy playing the same old tired political game of pin-the-latest-failure-on-the-party-you-hate.
the culture of the banking cartels, whose dynastic families have a somewhat different ethnic background.....
The people who most need it end up being the people who can least afford it.
The issue is even more serious than how you describe it here. Its not that they can't afford it (although that is obviously a major problem itself), its that the option simply isn't available to them at all. With health care and private-only insurance we have the existence of millions of "uninsurables", people who can't get insurance at any price, and with a private-only mail/package delivery, we'd have a significant part of the country simply being entirely unsupported because deliveries to their region would be unprofitable.
Having so many rural regions economically isolated from the rest of the country was one of the reasons for the later expansion of the USPS to rural areas in the first place.
The important thing is to be honest about the pros/cons of the various models of funding these kinds of activities, and then allow society to choose what kind of a world we want to live in.
True, I suspect a lot of posters here just haven't thought through the long term consequences.
Without universal mail/package delivery, and without the government-supported expansion of the country's highway and road networks which followed by necessity, and later the decision to make telephone service universal as well, this country would not be, and could not have become, what it is today.
Just think of the billions (trillions?) of dollars worth of business and commerce that has occurred over the decades, which would not have otherwise happened without universal mail/package delivery & telephone service.
How ironic (given some of the posts in this thread) that all that "socialism" turned out to be so good for business.:)
"This seems to be where Linux's strength is - replacing proprietary Unix."
That is real funny, because Sun's real strength was replacing proprietary mainframes with their own open systems.
I'm not sure I understand you here. Until OpenSolaris & their use of x86 hardware, wasn't Sun (hardware & OS) just as proprietary as the mainframes? Wasn't Sun's success really because their solutions were technically sound, high quality, *and* much cheaper than the absurdly expensive mainframes of the day?
Now UNIX is proprietary (codeword for not having a rational reason for disliking something),
??
and Linux on a freaking zSeries is okeydokey. What the F?
From my reading, they already had the mainframe, and they saw no reason to ditch hardware that still worked well for them. As "hardware" goes, a zSeries mainframe *is* fairly impressive, after all.:)
I guess IBM's logic is that by having the same OS on your mainframe, and your open systems, you're not locked into IBM mainframe hardware?
IBM's philosophy is that they sell hardware & support for that hardware. Software is just part of that support, its primarily a service, not a product to them. This is why they were an early adopter of Linux, they're customers wanted it, so they provided it to them. As long as you keep in mind that IBM is *hardware-centric*, then IBM's logic makes perfect sense, after all, their customer in this case is *still* using their hardware. If IBM were less flexible on the software side, they may have lost this customer, and likely many others over the years...
If you still have to port your cobol to a new OS, why not run it on cheaper open system hardware.
Which would then not only be a port to a new OS but to a new hardware platform as well, never mind needing to buy that new hardware. I think the old saying "If it ain't broke..." applies here.:)
I think the summary and the TFA are a bit confusing. It probably would have been better had the summary linked not just to the TFA but also directly to the gcn.com article which is linked to from TFA, or maybe better yet, just to the gcn.com article. What I get from that gcn.com article is this:
a) There is a mainframe that is talking to ~1300 "midrange" servers.
b) The mainframe is an IBM Z-series which has been shifted over from an IBM proprietary OS to Novell SUSE Linux.
c) The COBOL code is running on the *mainframe*, not the ~1300 servers! (TFA summary is wrong on this)
d) Because the mainframe is now running Linux, and because of a USPS IT decision to standardize on Linux (this is why OpenSolaris was never an option - sorry OpenSolaris fans), they're now converting the servers to Linux as well for better interoperability between the mainframe environment and server environments.
e) As for what this system is actually tracking:
Events are transactions that occur at the service's retail counters, such as shipping and picking up packages or the delivery of priority mail by carriers to businesses and residences. The mail is scanned to confirm delivery, and that information is sent to the PTS database....
âoeWe're inserting like 40 million events a day,â he added....
The PTS has 56 transaction types, such as acceptance scans and delivery confirmations, that have now all been migrated to Linux.
The gcn.com article has more info, but even it is confusing to me. Questions:
What is an "HP Linux Environment" (Does HP have its own version of Linux? What distro is HP using?)
Any Z-series gurus reading this want to chime in and explain what the IFL actually is (Page 2 of article)?
Yes, I know, I could Google for those answers, but I'm already worn out just doing what the original story submitter should have done. Just consider the above an "improved summary".:)
But Java has been around for years,... Java desktop applications had plenty of time to gain marketplace momentum,
True (although FWIW, the last complete PC that I bought did not include Java), and nor will I argue about the technical flaws of Java, they can and are being fixed, but they exist now and are real. The main difference is what I alluded to, that Java has always been trying to be cross-platform, something which MS obviously doesn't care about.
It still never took off.
Well, besides Java's technical problems that I mentioned, MS also played a role in this as well. They never wanted Java to succeed because they didn't control it. Once the embrace&extend of Java failed,.NET became "Plan B".
the window of opportunity is closed.
On the Windows platform, certainly. That was inevitable once MS released.NET. NET has little to no relevance to the other platforms however, and I don't believe Mono can change that.
Everyone knows why MS created NET, and I believe *most* people on non-Windows platforms know not to touch it, even with a ten-foot pole.
Well, not always. The more paranoid commenters here have tried to raise a controversy over the use of C# itself
Ok, you got me there. However, I always considered those posters to be anti-Mono and/or anti-MS trolls, and never really counted their posts as legitimate arguments either.:)
There is no question in my mind that what is specifically covered under the ECMA agreements is 'safe'.
but hopefully the legally binding "community promise" will put an end to that.
Maybe, maybe not. Depends on who you ask.:)
Take a look at the top of my other post. That Open Specification Promise reference by the parent is that 'community promise', and I pointed out that it only specifically mentions the XAML scripting language, nothing about the "rest of Silverlight". The actual text of it can be found on MS's site as well as Wikipedia. The first link in that post is to a criticism of MS's 'Covenant to Downstream Recipients of Moonlight' by a para-legal, and that sounds even more problematic to me, nor is this the only place such criticism can be found. I'm not a lawyer, so who to believe? Everybody's got an agenda it seems, especially the shills & trolls (both pro- and anti-) here.
I don't believe there's any evidence that WinForms, ASP.NET, or ADO.NET are actually covered by patents at all,
Right, thats one of the fundamental problems of our patent system. We won't know anything for sure unless MS sues somebody, and if they don't sue, we'll *never* know for sure.:(
I think people would become interested very quickly if Microsoft actually made a move toward stopping Mono
Which is exactly why they'll hold off for as long as they feel they can. They know it would be a PR disaster, not to mention being possible evidence of monopolistic behavior, that could be used against them in a legal proceeding. Right now, Mono doesn't really hurt them, while simultaneously muddying the waters and giving them "good cover", i.e., "See EU, we *are* cooperating with other non-Windows platforms, and even 'supporting' FOSS software!". Those things are probably worth a great deal to them, so they might put up with a lot of internal "concern" about Mono, just to get that positive PR, and, if Mono/Moonlight struggles to keep up, and is always a couple steps behind, they may *never* sue, as the benefits of keeping Mono/Moonlight around as token proof of MS's benevolence to the non-Windows world may outweigh any damage that Mono/Moonlight really does to them.
it wasn't a program running on Windows, it was only present in a beta release
MS stopped another program from running on a released version of Windows. You never specified anything about beta/non-beta status, it was released to the public however.
Qt takes the form: connect(producer, signal, consumer, slot), and it goes without saying that making a connection between two things is always going to require specifying what those two things are!
producer & consumer are 'const QObject*', so no, the consumer doesn't need to know *exactly* what the producer is, as long as its derived from QObject (which it must be in Qt). All Qt's connect needs is a *pointer*. The signal and slots are wrapped by macros, so moc will take care of them, without the consumer and producer needing to know the details of each other (except for the *names* of the signals and slots of course).
'p.sig.setCallBack()' is a method call *into* the producer, but connect(ptr,SIG(sig),ptr,SLOT(slot)) is a method call provided by the consumer's QObject base class, the equivalent of 'this->connect(...)'. Can't you recognize the difference between 'p.sig.X()' and 'this->X()'???
For the consumer to be able to call 'p.sig.X', you'll have to give it the producer's class definition so it knows about 'sig'. Put your Consumer and Producer in separate files and see what kind of #includes you'll end up needing to make it work.
Anyway, agree or not (let me guess, you don't), the appearance of insults means I'm done here. Flame away.
I just used it for clarity - I don't like calling things "class" unless they are classes.
I understand that and know why you did it, just trying to point out the kind of problems TT had when they started: a lot of what we take for granted now didn't exist back then.
Huh? The connection is made entirely external to, without modifying and without the knowledge of producer or consumer!
without access to the producer, the 'p.sig.' part?
Both Qt and Boost.signals2 have their 'connect' (your 'setCallBack') and 'emit' mechanisms as standalone operations(*). You made 'sig', your callback mechanism, part of, e.g. owned by, the producer. Your 'sig' needs to be separate, so the consumer can set the callback without needing to know who the producer is.
Your example is a valid example of a callback mechanism, just not, it looks to me, a "loosely coupled" one, and with Qt and Boost.signals2, the producer and consumer aren't coupled at all.
(*) Although technically, Qt implements part of it in QObject, which both producers and consumers must inherit from, with the rest of the magic provided by moc.
but you see, most users also don't write applications, and as long as you try to feed BS to the later group of people, you are going nowhere.
Until your boss gives you your marching orders.
What if he is his own boss?
Or his boss is just as concerned with interoperability and reaching the widest possible audience as he is? There are plenty of companies who value platform neutrality and net standards.
It's patented but under an irrevocable Open Specification Promise
Thats only for MS's XAML script language thats in Silverlight/Moonlight, there may be patents MS has on Silverlight that aren't related to XAML. And for Mono, the potential patent issues with Winforms, ADO.NET and ASP.NET still remain (is Moonlight using Winforms, or doing its graphics stuff using GTK via Cairo directly?) In any event, Mono/Winforms is still a minefield.
Wake me up when the Mono guys can clear up the issues discussed in the 'Mono and Microsoft's patents' section of Mono's wikipedia page, and the Moonlight guys can do the same for the 'Controversy' section on their wikipedia page, *and* MS changes the language of their 'Covenant' to include non-Novell users. Until then, Mono/Winforms & Moonlight are still non-starters for any non-Novell Linux distro or user.
it's actually safer to use than theora
Nice try.
As was pointed out in the argument over HTML5 we had a few days ago, using theora is no more dangerous than using H264, which in turn is no more, or less!, dangerous than using any other software that may have patents on it. We have no way of knowing if MPEGLA is the only entity that has patents on H264. This problem is simply inherent in our screwed-up software patent system.
Theora may not be safe. H264 may not be safe. Anyone claiming that one is clearly or definitely safer than the other is either uninformed, or trolling.
And since MPEGLA can change the license requirements at any time, including extending it to the distributors of H264 *content*, not just encoder/decoder implementors, as some believe they will soon do, this is just a rerun of the.GIF fiasco, only more inexcusable, because now we should know better.
Alas, some of us are stuck in countries that haven't yet figured out that software patents are insane.:(
On the other hand, from the arguments I've seen here, the EU hasn't *completely* closed the door yet on them either, i.e., I don't know what "allowed, but unenforceable" really means.
Wait, so I should use virtualization software to run a *second* OS on top of my primary OS so I can use a plugin in a web browser so I can see cute but meaningless graphics and annoying ads?
3) FREEDOS cloned DOS.... finally managed to catch a dead product after most people forgot it existed
This is just a nit-pick, but:
DOSEMU died because 'dosbox' took over.
There *are* people who still care, otherwise dosbox and freedos themselves would be dead projects. The issue is not popularity, or whether you think their goal was worthwhile or not, the important point you should have stuck to was that those two projects are tracking a "standard" that is obviously no longer changing.
WINE & ReactOS are obviously tracking a *moving* target (thats also big & "closed"), and its the tracking of a *moving* target (also "closed") that will be the serious problem Moonlight will have as well.
Slashdot Mirror
you need updating all the time to stay up to the list.
Did you miss the GP's "then only update those packages on the DoD's list."?
Unless that DoD list constitutes the bulk of a Linux system (100+ packages? - TFA only mentions 4!), then you still won't be "updating all the time", so your point is?
Gentoo is great for learning how to fix things that are broken.
Even assuming this breakage happens as often as you imply (not my experience), where does it say that *you* have to fix the problem? When something fails to download/build/verify, I just wait till the devs fix it. Your current system isn't touched until the final install step, and I honestly can't remember the last time I saw the final install step fail.
config file syntax has changed subtly
Config files are normally updated at install time. For those that you want to control changes to, you use something like dispatch-conf or etc-update to review changes before allowing them, at which point you'll notice the change - if you're paying attention (if you aren't then don't blame Gentoo). Of all the kinds of breakage I see, this kind is the rarest, IMO. Most breakage is of the failed-compile variety, at which point you just mask that version of the package and wait for the fixed version.
If that option changes the semantics of the language, it's not an optimization.
The "semantics of the language" don't help us since, in this case, we were already in "Undefined Behavior" territory by the time of the ptr check.
Which I hope the compiler guys will decide, and fix it
Looks like the kernel guys have gone with one of the other options I mentioned, they are explicitly turning off that optimization option for a kernel build.
http://it.slashdot.org/comments.pl?sid=1307017&cid=28747953
Note the last two paras in that post, and in particular: "(I think the argument that the gcc optimization is generally a bug have been sufficiently debunked, it's busted tunneling code, no ifs ands or buts)"
No, it should be in the -fthis-is-not-a-c-compiler -fyes-I-really-mean-it options -fyes-I-am-an-idiot-why-do-you-ask.
This is an utterly silly response given the complex situation of this particular error:
1) A language which allows for implementations to handle NULL differently. C doesn't have a strict clear specification for how to handle NULL derefs, or for that matter, even what NULL ultimately equates to, precisely *because* its used in so many different environments.
2) Invalid code to begin with (a ptr check after the ptr had already been used)
3) That bad code, even *with* the ptr check removed, would normally have PANICed the kernel, *except* when a linux security module was loaded that *allowed* valid memory to be mapped to addr 0, which *violated* a basic premise of GCC (and most C compilers). This point is the biggie: its extremely linux-specific, how in the hell can a cross-platform compiler (that is not linux specific) have handled this situation, or even *known* about it, never mind what the C Standard says about this, or more accurately, what it *doesn't* say?
4) an optimization option that (we now know) shouldn't have been used for the kernel (now fixed - see the post above).
Notice how it took *several* things, in sequence, to "go wrong" for this error to occur?
And point #4 is I believe the real issue: a "user" of the GCC compiler was not setting up GCC to properly handle their obviously unusual environment. The onus should be on the *user* to use the tool properly, not for the tool to just "magically know" how it should behave in wildly different environments. Indeed, how *could* it possibly know what do in this complex case? It seems from the post above, that the "user" in this case (the linux kernel), is doing exactly that: telling GCC not to do something that isn't valid for their environment (but is perfectly valid for *most* other users, e.g., the compiling of *applications*, as opposed to a complex operating system kernel).
Suggesting that we go back to more conservative compilers that don't attempt significant optimizations (which ultimately *requires* the modification and even *removal* of source code from the output) just isn't realistic at all. The world seems to be actually headed in the opposite direction: compilers that optimize even more aggressively.
The compiler assumed that if tun had been dereferenced, it couldn't be NULL.
Well, technically, the compiler assumed that since it had been given the '-fdelete-null-pointer-checks' optimization option, that that was what you wanted it to do. :)
That's a false assumption
The author's of that compiler optimization *knew* that it was a false assumption "for some environments". Read that option's description. This wasn't a bug in the typical sense, e.g., an accident or unintended behavior. The issue appears to be a little more interesting:
a) Should this option have been included by default in the -On options that it was (2/3/s)? Perhaps it should have been restricted to just -O3, where the "dangerous" optimizations supposedly live?
b) How are compiler author's to decide what opts are used for a given -On? If an optimization that is useful for, say, 90%(*) of compiler users, should it be included and on by default, or are you/others suggesting an optimization should only default to on if its valid for *all* compiler users? Who should carry the burden of taking explicit actions to keep the compiler from doing something thats not useful, or simply invalid, in their environment, the 90%, or the 10%?
c) Do the kernel devs have *some* responsibility here (aside from the mistake in the code itself)? Perhaps the kernel make should have been explicitly turning this option off, because in the kernel environment, this optimization is *not* useful? After all, if an app plays with a null pointer, just the app stops, but if the kernel does the same thing, the whole world might come crashing down. :) Those two environments obviously need to handle null pointers a bit differently...
Note: I'm not arguing for/against the kernel devs or the compiler devs, I'm just asking.
(*) I pulled the 90/10 ratio out of thin air, its just for discussion's sake. The compiler devs probably have a better idea of how broadly useful this particular option really is... or do they? :)
Thus, he couldn't test for null before initializing.
Of course he could. 'recommended style' != 'required rule'
In fact, in the very next function that follows the function with the bug in tun.c, there is an uninitialized variable being declared, and then initialized later, *after* a sanity check. In hindsight, this should have been done here too.
I'm guessing the author probably just made an honest mistake of looking at the code above:
and thinking that the __tun_get function, which initializes the tun pointer, wouldn't return a NULL. We now know it obviously can, so perhaps he simply forgot or misremembered that.
If the kernel were using C99, the programmer could have done his argument sanity checks first
Programmers still make mistakes when using C99 too. After all, this *is* pointer-heavy C we're talking about here. :)
Everytime I try to use Linux I always end up needing to compile the kernel
Every time? Always? Wow, such strong words, pity you don't back them up with anything.
a better tool than menuconfig/xconfig
The tool isn't the problem, IMO, its the sometimes incomplete and/or confusing descriptions of the config options which tend to trip people up. Of course, this is why all the main distros compile the kernel for you. No one ever said doing it yourself was easy (or was even supposed to be). Hell, when is doing *anything* yourself "easier" than having someone do it for you?
there is no place for me on Linux.
Actually, I'm wondering just how hard you actually tried to make a place for yourself...
I am more then a user but not a system/kernel programmer.
"system/kernel programmers" aren't the only people who compile their own kernels.
Something I would think Linux developers/distros would be very concerned about.
Why do you think all the major distros provide their users with precompiled kernels?
It's just another thing stopping Linux from more a widespread adoption.
Being able to compile the kernel yourself has absolutely nothing to do with Linux's lack of popularity, and you've made no attempt to show that anyone *has* to compile it...
idiot prepackaged environments
You do realize this description basically applies also to Windows & Mac OS, not just to all of the most popular Linux distros in use, don't you? "idiot" just doesn't make any sense here.
make your environment all by yourself
"Linux from Scratch" is the *only* "distro" that actually requires that.
through years of personal experience in system level software design/programming
Hyperbole much?
Many, many people compile the kernel on a routine basis without ever looking at the source code.
But that's how it is I guess.
That would only be true if your "it" was in any way remotely connected with reality...
Of course it doesn't help that you started off with a vague reference to "problems that require you to compile the kernel yourself", without, unfortunately, any specifics at all. You'll need to actually give a real example of this kind of "problem" before anyone can take you seriously...
Um, 80 != 0, right?
Wrong. There is no requirement that FLOSS software be available at no charge. Its the source code which must be made available at no charge.
So, why would the F/OSS community trumpet this as a "win"?
Because we've had to listen to trolls, shills, and the ignorant tell us for years that "no one is going to make money selling FLOSS software", and for years we've tried to explain the difference between paying for the software (software as a monetized "product"; profit derives from the software itself) and paying for customer support to use the software (software as a commodity; profit derives from services provided with the software), but to no avail. Heck, even after all this time, we've still got trolls using "communism" in the same sentence with FLOSS.
1. People didn't pay RH $80 for the software, they paid them $80 for customer support...
2. And RH is successfully making money over the long term doing it...
3. Even though the underlying software is FLOSS.
Lines 2 & 3 above are why this is a "win" for us, not line 1.
When explanations fail, whether because they have fallen on deliberately deaf, or merely ignorant, ears, then there is nothing better than a working example... and thats exactly what RH is.
The Obama administration is the one propping up all manner of failed business models with "bailouts".
Huh? The GP's post was entitled "CIT and moral hazard". Well, CIT is NOT being bailed out, and "moral hazard" was the reason used by the Fed under the *previous* administration for NOT bailing out the second corp that got into trouble (Lehman Bros., I believe), so actually *neither* the present or the previous administrations have bailed out "all manner of failed business models".
Instead of trying to blame Bush or Obama for the whole mess, why the hell don't we deal with the real issue here, which is that a free market system which accepts the concept of "too big to fail" is NOT really a free market! We don't seem to talk about that problem as a society because we're too busy playing the same old tired political game of pin-the-latest-failure-on-the-party-you-hate.
the culture of the banking cartels, whose dynastic families have a somewhat different ethnic background.....
And this is just a troll.
The people who most need it end up being the people who can least afford it.
The issue is even more serious than how you describe it here. Its not that they can't afford it (although that is obviously a major problem itself), its that the option simply isn't available to them at all. With health care and private-only insurance we have the existence of millions of "uninsurables", people who can't get insurance at any price, and with a private-only mail/package delivery, we'd have a significant part of the country simply being entirely unsupported because deliveries to their region would be unprofitable.
Having so many rural regions economically isolated from the rest of the country was one of the reasons for the later expansion of the USPS to rural areas in the first place.
The important thing is to be honest about the pros/cons of the various models of funding these kinds of activities, and then allow society to choose what kind of a world we want to live in.
True, I suspect a lot of posters here just haven't thought through the long term consequences.
Without universal mail/package delivery, and without the government-supported expansion of the country's highway and road networks which followed by necessity, and later the decision to make telephone service universal as well, this country would not be, and could not have become, what it is today.
Just think of the billions (trillions?) of dollars worth of business and commerce that has occurred over the decades, which would not have otherwise happened without universal mail/package delivery & telephone service.
How ironic (given some of the posts in this thread) that all that "socialism" turned out to be so good for business. :)
"This seems to be where Linux's strength is - replacing proprietary Unix."
That is real funny, because Sun's real strength was replacing proprietary mainframes with their own open systems.
I'm not sure I understand you here. Until OpenSolaris & their use of x86 hardware, wasn't Sun (hardware & OS) just as proprietary as the mainframes? Wasn't Sun's success really because their solutions were technically sound, high quality, *and* much cheaper than the absurdly expensive mainframes of the day?
Now UNIX is proprietary (codeword for not having a rational reason for disliking something),
??
and Linux on a freaking zSeries is okeydokey. What the F?
From my reading, they already had the mainframe, and they saw no reason to ditch hardware that still worked well for them. As "hardware" goes, a zSeries mainframe *is* fairly impressive, after all. :)
I guess IBM's logic is that by having the same OS on your mainframe, and your open systems, you're not locked into IBM mainframe hardware?
IBM's philosophy is that they sell hardware & support for that hardware. Software is just part of that support, its primarily a service, not a product to them. This is why they were an early adopter of Linux, they're customers wanted it, so they provided it to them. As long as you keep in mind that IBM is *hardware-centric*, then IBM's logic makes perfect sense, after all, their customer in this case is *still* using their hardware. If IBM were less flexible on the software side, they may have lost this customer, and likely many others over the years...
If you still have to port your cobol to a new OS, why not run it on cheaper open system hardware.
Which would then not only be a port to a new OS but to a new hardware platform as well, never mind needing to buy that new hardware. I think the old saying "If it ain't broke..." applies here. :)
What is an "HP Linux Environment"
Wait a sec... from article:
USPS is using Novell's SUSE Linux on the mainframe and distributed computing platforms...
Maybe 'distributed computing platforms' == the 1300 servers, so they're using SUSE Linux on all the hardware?
I think the summary and the TFA are a bit confusing. It probably would have been better had the summary linked not just to the TFA but also directly to the gcn.com article which is linked to from TFA, or maybe better yet, just to the gcn.com article. What I get from that gcn.com article is this:
a) There is a mainframe that is talking to ~1300 "midrange" servers.
b) The mainframe is an IBM Z-series which has been shifted over from an IBM proprietary OS to Novell SUSE Linux.
c) The COBOL code is running on the *mainframe*, not the ~1300 servers! (TFA summary is wrong on this)
d) Because the mainframe is now running Linux, and because of a USPS IT decision to standardize on Linux (this is why OpenSolaris was never an option - sorry OpenSolaris fans), they're now converting the servers to Linux as well for better interoperability between the mainframe environment and server environments.
e) As for what this system is actually tracking:
Events are transactions that occur at the service's retail counters, such as shipping and picking up packages or the delivery of priority mail by carriers to businesses and residences. The mail is scanned to confirm delivery, and that information is sent to the PTS database. ...
âoeWe're inserting like 40 million events a day,â he added. ...
The PTS has 56 transaction types, such as acceptance scans and delivery confirmations, that have now all been migrated to Linux.
The gcn.com article has more info, but even it is confusing to me. Questions:
What is an "HP Linux Environment" (Does HP have its own version of Linux? What distro is HP using?)
Any Z-series gurus reading this want to chime in and explain what the IFL actually is (Page 2 of article)?
Yes, I know, I could Google for those answers, but I'm already worn out just doing what the original story submitter should have done. Just consider the above an "improved summary". :)
But Java has been around for years, ... Java desktop applications had plenty of time to gain marketplace momentum,
True (although FWIW, the last complete PC that I bought did not include Java), and nor will I argue about the technical flaws of Java, they can and are being fixed, but they exist now and are real. The main difference is what I alluded to, that Java has always been trying to be cross-platform, something which MS obviously doesn't care about.
It still never took off.
Well, besides Java's technical problems that I mentioned, MS also played a role in this as well. They never wanted Java to succeed because they didn't control it. Once the embrace&extend of Java failed, .NET became "Plan B".
the window of opportunity is closed.
On the Windows platform, certainly. That was inevitable once MS released .NET. NET has little to no relevance to the other platforms however, and I don't believe Mono can change that.
Everyone knows why MS created NET, and I believe *most* people on non-Windows platforms know not to touch it, even with a ten-foot pole.
Ok, you got me there. However, I always considered those posters to be anti-Mono and/or anti-MS trolls, and never really counted their posts as legitimate arguments either. :)
There is no question in my mind that what is specifically covered under the ECMA agreements is 'safe'.
Maybe, maybe not. Depends on who you ask. :)
Take a look at the top of my other post. That Open Specification Promise reference by the parent is that 'community promise', and I pointed out that it only specifically mentions the XAML scripting language, nothing about the "rest of Silverlight". The actual text of it can be found on MS's site as well as Wikipedia. The first link in that post is to a criticism of MS's 'Covenant to Downstream Recipients of Moonlight' by a para-legal, and that sounds even more problematic to me, nor is this the only place such criticism can be found. I'm not a lawyer, so who to believe? Everybody's got an agenda it seems, especially the shills & trolls (both pro- and anti-) here.
Right, thats one of the fundamental problems of our patent system. We won't know anything for sure unless MS sues somebody, and if they don't sue, we'll *never* know for sure. :(
Which is exactly why they'll hold off for as long as they feel they can. They know it would be a PR disaster, not to mention being possible evidence of monopolistic behavior, that could be used against them in a legal proceeding. Right now, Mono doesn't really hurt them, while simultaneously muddying the waters and giving them "good cover", i.e., "See EU, we *are* cooperating with other non-Windows platforms, and even 'supporting' FOSS software!". Those things are probably worth a great deal to them, so they might put up with a lot of internal "concern" about Mono, just to get that positive PR, and, if Mono/Moonlight struggles to keep up, and is always a couple steps behind, they may *never* sue, as the benefits of keeping Mono/Moonlight around as token proof of MS's benevolence to the non-Windows world may outweigh any damage that Mono/Moonlight really does to them.
But as you say, its 'for now'. :)
Saying its so, doesn't make it so.
No offense, but I trust groklaw more than an unknown /. poster.
MS stopped another program from running on a released version of Windows. You never specified anything about beta/non-beta status, it was released to the public however.
As I suspected, you're a shill.
Qt takes the form: connect(producer, signal, consumer, slot), and it goes without saying that making a connection between two things is always going to require specifying what those two things are!
producer & consumer are 'const QObject*', so no, the consumer doesn't need to know *exactly* what the producer is, as long as its derived from QObject (which it must be in Qt). All Qt's connect needs is a *pointer*. The signal and slots are wrapped by macros, so moc will take care of them, without the consumer and producer needing to know the details of each other (except for the *names* of the signals and slots of course).
'p.sig.setCallBack()' is a method call *into* the producer, but connect(ptr,SIG(sig),ptr,SLOT(slot)) is a method call provided by the consumer's QObject base class, the equivalent of 'this->connect(...)'. Can't you recognize the difference between 'p.sig.X()' and 'this->X()'???
For the consumer to be able to call 'p.sig.X', you'll have to give it the producer's class definition so it knows about 'sig'. Put your Consumer and Producer in separate files and see what kind of #includes you'll end up needing to make it work.
Anyway, agree or not (let me guess, you don't), the appearance of insults means I'm done here. Flame away.
I just used it for clarity - I don't like calling things "class" unless they are classes.
I understand that and know why you did it, just trying to point out the kind of problems TT had when they started: a lot of what we take for granted now didn't exist back then.
Huh? The connection is made entirely external to, without modifying and without the knowledge of producer or consumer!
How can the "consumer" establish the callback:
without access to the producer, the 'p.sig.' part?
Both Qt and Boost.signals2 have their 'connect' (your 'setCallBack') and 'emit' mechanisms as standalone operations(*). You made 'sig', your callback mechanism, part of, e.g. owned by, the producer. Your 'sig' needs to be separate, so the consumer can set the callback without needing to know who the producer is.
Your example is a valid example of a callback mechanism, just not, it looks to me, a "loosely coupled" one, and with Qt and Boost.signals2, the producer and consumer aren't coupled at all.
(*) Although technically, Qt implements part of it in QObject, which both producers and consumers must inherit from, with the rest of the magic provided by moc.
but you see, most users also don't write applications, and as long as you try to feed BS to the later group of people, you are going nowhere.
Until your boss gives you your marching orders.
What if he is his own boss?
Or his boss is just as concerned with interoperability and reaching the widest possible audience as he is? There are plenty of companies who value platform neutrality and net standards.
Please see my other post downthread. Using Moonlight on a non-Novell Linux distro may have issues.
Thats only for MS's XAML script language thats in Silverlight/Moonlight, there may be patents MS has on Silverlight that aren't related to XAML. And for Mono, the potential patent issues with Winforms, ADO.NET and ASP.NET still remain (is Moonlight using Winforms, or doing its graphics stuff using GTK via Cairo directly?) In any event, Mono/Winforms is still a minefield.
And this still doesn't deal with the extremely problematic language (which is still there) of MS's 'Covenant to Downstream Recipients of Moonlight'. Going by that obtuse document, the only people safe from MS's lawyers are ones running Moonlight in a browser on Novell Linux, everyone else is fair game.
Wake me up when the Mono guys can clear up the issues discussed in the 'Mono and Microsoft's patents' section of Mono's wikipedia page, and the Moonlight guys can do the same for the 'Controversy' section on their wikipedia page, *and* MS changes the language of their 'Covenant' to include non-Novell users. Until then, Mono/Winforms & Moonlight are still non-starters for any non-Novell Linux distro or user.
Nice try.
As was pointed out in the argument over HTML5 we had a few days ago, using theora is no more dangerous than using H264, which in turn is no more, or less!, dangerous than using any other software that may have patents on it. We have no way of knowing if MPEGLA is the only entity that has patents on H264. This problem is simply inherent in our screwed-up software patent system.
Theora may not be safe. H264 may not be safe. Anyone claiming that one is clearly or definitely safer than the other is either uninformed, or trolling.
And since MPEGLA can change the license requirements at any time, including extending it to the distributors of H264 *content*, not just encoder/decoder implementors, as some believe they will soon do, this is just a rerun of the .GIF fiasco, only more inexcusable, because now we should know better.
If your web browser itself is 64bit, and nothing else in your system requires 32bit?
Not saying Adobe was under any obligation to provide it, just that your definition of "stupid" is definitely different from mine.
Alas, some of us are stuck in countries that haven't yet figured out that software patents are insane. :(
On the other hand, from the arguments I've seen here, the EU hasn't *completely* closed the door yet on them either, i.e., I don't know what "allowed, but unenforceable" really means.
Wait, so I should use virtualization software to run a *second* OS on top of my primary OS so I can use a plugin in a web browser so I can see cute but meaningless graphics and annoying ads?
No comment. :)
This is just a nit-pick, but:
DOSEMU died because 'dosbox' took over.
There *are* people who still care, otherwise dosbox and freedos themselves would be dead projects. The issue is not popularity, or whether you think their goal was worthwhile or not, the important point you should have stuck to was that those two projects are tracking a "standard" that is obviously no longer changing.
WINE & ReactOS are obviously tracking a *moving* target (thats also big & "closed"), and its the tracking of a *moving* target (also "closed") that will be the serious problem Moonlight will have as well.