Comment Re:Cost (Score 1) 214
Actually, the IDF F4s, F15s, F16s and Kfir C-2s faced a lot of MIG-23's in the first Lebanon war.
As far as I recall the war ended at 86:0.
- Gilboa
Actually, the IDF F4s, F15s, F16s and Kfir C-2s faced a lot of MIG-23's in the first Lebanon war.
As far as I recall the war ended at 86:0.
- Gilboa
". In the area of drivers, kernel"
I call bullshit.
As someone that in the past ~8 years have been maintaining a *separate* proprietary kernel tree that includes a fairly large OS dependent multi-platform kernel library and multiple drivers (all in all, > 250K LOC covering everything from files to networking) I can can only wonder if why this stupid claim haven't died a horrible, horrible death long, long ago..
All in all, I doubt that I spent more than 2 hours *per* kernel release to track the latest kernel API changes. *
BTW, when asked (by Phoronix, I think), nVidia Linux kernel engineers more-or-less shared the same experience. (And I assume that their code based is somewhat (...) bigger than mine).
Care to share opposite experience?
- Gilboa
* I which I could have said the same about maintaining a *small* portion of this code base across different Windows versions and even, at times, across different SP releases.
*Come-on* people. English may not be my first language, but anyone what basic fourth grade reading comprehension skills should have understood that "Do yourself a favor and read a book (or two) about the Holocaust before you compare *ANYONE* to Nazi Germany" means I was being sarcastic and that I **do not** believe the U.S. can be compared to Nazy Germany. This ain't rockets science.
Guess I should have marked the post with "Sarcasm" in huge, bold, capital letters...?
- Gilboa
Re-read my comment *SLOWLY*.
Now idea how this:
"Do yourself a favor and read a book (or two) about the Holocaust before you compare *ANYONE* to Nazi Germany. (And no, Mein Kampf is *not* what I meant, you illiterate pi^H^H^H^H^H^H.)" Could be understood as me comparing the U.S. to Nazi Germany.
(Quite the opposite, It was a sarcastic remark about the OP's "America is is just as bad as the Nazies" post)
English may not be my first language, but come on!
- Gilboa
... Because the Americans took millions of people, shove them into 3sq km Ghettos where they'll die, in the millions from hunger and disease.
Those who were lucky enough to survive the Ghettos (and God knows how many forms of random murders) were then taken to huge camps in the middle of NY state, where they were gassed.
Do yourself a favor and read a book (or two) about the Holocaust before you compare *ANYONE* to Nazi Germany. (And no, Mein Kampf is *not* what I meant, you illiterate pi^H^H^H^H^H^H.)
- Gilboa
P.S. I'm not even American. Not even close.
Nothing in the linked bug report suggests that Linux is being mis-threated and/or ignored.
- Gilboa
"Pros and cons. And if not happy about it buy an Android, competition is good
In a perfect world, I'd most likely would have agreed with you.
However, given the fact that both MS and Apple are both doing their best to kill Anroid by using the err, justice (?) system (and having participated in writing more than one patent I'm well aware how awful/broken/absurd the patent system), let alone trying to block non-signed OS from being installed on ARM systems ('Secure"-boot, soon to be on x86_64, I'd imagine) - you too, should be *very* worried if this story is indeed true. (I've yet to RTFA)
- Gilboa
... While I don't use bitmap background in konsole, I use colored background / foreground -alot-.
I use a color coding system to visually identify the machine (localhost, SSH, telnet-to-serial-on-KVM-guest, remote-serial-console, etc), user (me, root, test, etc) and site (work, home, etc).
Now it might sound overkill, but when you have 10+ tabs open, you *really* need some way to make sure you don't type 'rm -rf $PWD' in the wrong tab....
I just may use bitmapped console background to tag dangerous tabs (E.g. pirate flag in root@X tabs)
- Gilboa
... The irony is that argument itself is more-or-less meaningless.
Much like the CISC vs. RISC argument, in the end, the hybrid design took the gold medal.
Even the so-called-monolithic Linux, uses fuse, libusb and libpcap to develop low-level user-land applications.
- Gilboa
As we are using moronic (and intelligence insulting) examples, please let me summarize the argument is just-as-insulting mode:
Me: In *my* use-case, micro-kernel's main feature (recoverability) is useless. Plus, there's the issue of performance and added complexity which renders the basic idea of Micro-kernel design irrelevant.
You: Micro-kernel is shiny! It makes your system "understandable", "well structured" and "reusable"!
Me: No it won't. <insert long explanation why a micro-kernel DPI will suck when layered and suck just as bad when not layered>.
You Repeat previous argument + hint at me being an idiot.
Me: Try to end the argument pointing out that while your mind boggling nice-and-shiny theories amaze me, I rather go peel an apple.
You: Strongly hint that I'm an idiot.
Me: *Singing loudly* I really like peeled apples! *Singing loudly*.
- Gilboa
I never said micro kernel (as a general concept) isn't useful to *some* use cases; I was showing that much like the OP's point, the possibility of recovery may be completely meaningless in many use cases.
- Gilboa
No offense but this argument remains the following argument from a movie called Idiocracy:
"But Brawndo got what plants crave, its got electrolytes"
"What are electrolytes? Do you even now?
"Its what they use to make Brawndo!"
"Why they use it to make Brawndo?"
"Because Brawndo has electrolytes..."
Let leave it at that...
- Gilboa
In short, you more or less ignored my example and went with yet another theoretical explanation why micro-kernel is the kernel design to rule them all.
In reality, you didn't really try to debunk my previous claims: E.g. Sure, you can put the DPI + network cards in the same "protection domain" (much like in, err, a monolithic kernel...), but this more-or-less means that any crash, in any of the above-mentioned components (Network drivers, DPI, memory management) will result in what essentially amounts to a full reboot - let alone the fact that I've yet to see a well-marshaled IPC that's capable of pushing GBps of data without making the CPU bleed from the ears.
In essence, you post doesn't include any evidence that a micro-kernel will make my DPI software [i]understandable[/i], [i]well structured[/i] - let alone [i]recoverable[/i]. (See my previous post)
Beyond that, "understandable"? "well structured"? "reusable"? what exactly does it has to do with monolithic vs. micro-kernel? A monolithic kernel can be "well structured" and "well documented" and use a lot of "reusable components" while a micro-kernel can be badly structured w/ zero documentation and have the same functionality implemented differently in 1,000 different modules.
- Gilboa
Truth be told, if one of your drivers crashes, there's little hope of maintaining a useful system and you'll likely want to reboot anyway.
Except this isn't true of microkernel systems like Minix. And this is the point: microkernels enforce protection boundaries between components so failure and recovery become feasible. That simply isn't possible in a monolithic kernel without resorting to proof-carrying code of some sort.
(I'm a in-kernel DPI developer by trade; I'll stick to what I know)
Lets assume you need to develop an application firewall that needs to handle multiple 10GbE links.
In Linux, life is simple, you stuff a huge blob of code into the kernel, replacing the normal stack; sure, development is (more) difficult and debugging can exponentially increase your gray hair count by a number of factors, but it in the end, you get an skb, you read it, modify it, and dump it (or not) to the target network device. End-of-story.
In the Micro-kernel world, things are far more complicated.
As you put the network device and DPI software in separate user-spaces, you'll require an in-kernel mmap-like (?) message passing system in-order to connect the network driver(s) to the DPI software (and back) w/ complex memory management and device ring buffer control.
Lets assume that this interface has near-zero-performance penalty (and I *greatly* doubt it) and concentrate on the chances of recovering from a crash:
If a network device dies, it may or may not leave the *hardware* in recoverable state. Lets write this as 50% chance of recovery.
If the DPI software dies, you lose all the session and node information, which more-or-less amounts to a full reboot. Lets write this as 0% of chance recovery.
Now, if the fancy mmap interface dies... Well, you got the idea.
In short, at best, you have a better chance of recovering from a network device crash, which, in-case you ever looked at Ethernet driver code, is a ***very*** rare event - all of it at the price of a huge performance hit and packet flow that more-or-less impossible to debug.
- Gilboa
Gaah?
1. Linux has a *full* "generic" 802.11 stack.
2. Licensing issues will most likely prevent you from copying "BSD" parts into Linux, unless the original author allowed for dual GPL / BSD licensing (and I doubt it)
Could you please list a number of card that have been ported from FreeBSD w/ parts of the FreeBSD's 802.11 stack?
- Gilboa
After Goliath's defeat, giants ceased to command respect. - Freeman Dyson