It can't use an `int` as a key or value - it operated on pointers to something abstract. Meaning that not only that something has to be dynamically allocated, but that if it is small - like `int` or even `long` - the overhead of dynamic memory would (typically) quadruple memory consumption. Which is clearly why things like glib aren't used in kernel space.
For fuck's sake, *nix kernels have been implementing complex process and cycle allocation algorithms for four decades now, almost all of it written in C.
LOL. Thanks. As a system developer specializing on Linux, how could I have missed it!?
Seriously though, you might also note that it often took kernels also *decades* to get where they are.
Most algorithms are very very primitive - because you shouldn't put complex/unpredictable logic into the kernel.
Lion share of memory allocation is static. There are very few truly dynamic structures. Because kernel may not run out of memory (and kernel address space is often very limited).
Data structures are primitive - lists and hashes are the pillars - because everything else either has lower memory efficiency or has performance quirks.
It literally takes years to get it right.
Otherwise, if you are such a huge fan of C, please show me an implementation of binary tree in C which can be reused to store either `int` or `double` or `void *` data types in it. And no, crapload of preprocessor macros or type casts on every source code line do not cut it.
That's not even talking about various tools in userland that invoke fairly complex logic.
You seem to be either inexperienced or undereducated. Because you have missed the elephant in the room:
Complex logic != complex implementation.
And it's not like "complexity" has any formal definition.
Having seen and written plethora of C code in my life, I know well what C is capable of. But still, for any new development it is literally impossible to recommend C over C++.
Microsoft were unable to use
Unlikely. MSO is very old. Very likely the source code is poorly documented and not completely understood. Porting that to anything is going to be a major and very risky undertaking.
.NET has clearly failed.
Still clearly better than VB.
Raw C can be X-able.
It's just plain PITA to do it.
Otherwise, performance of the raw C is overrated. Or better: the developers who benefit most from C performance are the ones who can't algorithms. Also, developing reusable algorithms in C is a major PITA.
That doesn't sound like a proper native compiler:
The Native Image Generator (Ngen.exe) is a tool that improves the performance of managed applications. Ngen.exe creates native images, which are files containing compiled processor-specific machine code, and installs them into the native image cache on the local computer. The runtime can use native images from the cache instead of using the just-in-time (JIT) compiler to compile the original assembly.
Yes, it does produce native code.
No, it doesn't produce an executable, ready for redistribution.
I do not disagree with the approach, but there is still the difference. If done right, it might be a blessing: code is optimized for the local CPU. If done poorly (as MS likes to do it sometimes) it might mean irreproducible bugs or performance regressions and outright no effect at all, if cache gets corrupted somehow.
I haven't said Voyager was "very good".
All I said that, compared to the rest, it was watchable. It had some story. It had developing and changing character. Some characters were plain turn off, but still as a whole, the series left a marginally positive impression.
Original series have turned me off with the typical 60s machoismo.
TNG turned me off by the numerous episodes which had more elements in common with a soap opera or reality show than with a space saga.
I have expected an action or saga-like narrative, but all Star Trek has is a mild drama.
[...] unlikeable cast [...]
So a bald lady and a guys with face painted yellow are likable to you?
To me, at the very least, in the Voyager the lady captain had hairs. Hairs are huge IRL.
There are some soap opera episodes, I will give you that. I constantly cherry-pick from the rebroadcasts. But then who doesn't do this?
Babylon 5 has managed to avoid the soapness by having a story.
Or Stargate and Firefly - by having the episodes explore and develop the environment around the characters.
Every episode brought something new to the table.
I thoroughly enjoy the Data character (in addition to Picard) but I also like many "design" aspects of the series.
Data is probably the worst character of them all. He is just a "plot tool", the lowest form of "plot device": it gets screwed and bent all the time to create a short lived twist of the story. Few such eps later it is just "omg this time Data is {insert plot tool}, lol really?".
Resolution usually happens at the end of an episode, "good guys win" (otherwise, what's the point?), intelligent use of special effects.
The inherit problem with soap operas is that they lack development. IOW by the end of the episode the universe comes back to where it has started. Season ending "cliffhanger" episodes try to change something sometimes (and I personally not a huge fan of cliffhangers in general). But in Star Trek they fail to even do that.
... all of them? Seriously the inclusion of a trained Shakespearian actor (Stewart) was the only saving grace of that branch-off of TOS.
come on... it's not like the series didn't have any redeeming qualities at all... is it?
Forced myself through two seasons.
Nope. No redeeming qualities.
Ditto the original.
Voyager was somewhat watchable: several non-ridiculous characters, some non-ridiculous story, less of the "holodeck" ridiculousness.
Star Trek in general is too much of a soap opera to me to be enjoyable.
Litestep?
Wow. That brings memories. One of the few things which helped to use the WinNT 4.0 on 16MB RAM.
Have they finally fixes the tray? It was mostly broken why in the end I had to go back to the default shell (explorer.exe) instead.
Availability of alternative shells doesn't suddenly convert back all Metro applications into native Windows applications.
All they do is replace/bring back the start menu, so you see less of the Metro. But it is still there. You still can accidentally invoke it.
When compared to the Windows' Metro, which you can only try to avoid, yes, this is definitely a feature.
Maybe CentOS will succeed in getting the community behind it while simultaneously extending Linux's popularity beyond its current niche, but I fear that if Red Hat succeeds in making CentOS more popular and accessible then the community will just turn on them the minute they try something new.
That has already happened - with the Red Hat Linux 8 & 9, the predecessor of Fedora.
I was there and the results were not pretty. I mean: it looked very very pretty, but the rest of it was turning ugly very often.
Red Hat is too much of a mindless corporation to deliver any innovation. (On desktop one needs to tell users what to do - RH fails at that. Mindlessness works on server side, because there customers are engineers and can tell you what they need.)
Canonical's problem is that they overplay a visionary. That obviously hurts ego of way too many F/LOSS developers. Thus the bitterness. The thing many miss when criticizing Canonical's decisions is that they are pretty small company with very limited resources: they simply do not have the weigh to skew the whole Linux landscape. It is IMO miracle that they have managed to get as far they have got.
... they and Shuttleworth disappeared up their own backsides in a blinding flash of self importance and inability to listen to users (Unity - the OSS version of Windows 8 Metro, need I say more). I'm afraid their We Know Best doesn't tend to adhere them to many people and
The same load of BS is repeated over and over again. That doesn't make it true.
Unlike Metro:
1. Unity actually provides some benefits. Like for example full screen zoom on smaller laptop screens.
2. It breaks much less of UI conventions.
3. You can actually replace Unity with something else within minutes. (Or you can even install the Ubuntu edition without it.)
First two are also applicable to GNOME3 v. Unity comparison.
I suspect they've now peaked in terms of their importance in the free software world and will slowly fade away as the years go by.
Yeah. Ubuntu is going to be replaced by Mint. Oh wait, Mint *is* an Ubuntu-based distro.
Aaron also raised the problem which the larger Free Software community is trying to fix – reduce duplication of work.
Part of why Linux (IMO) succeeded was the duplication.
Because if you carefully evaluate the duplication, lots of it is not really duplication - but it is the choices, we are free to make.
Take away the "duplication" and you end up with something close-minded as Java, Windows or Mac OS.
The only "negative" of the duplication I have seen so far is the hurt ego of the competing developers.
The Linux desktop is more consistent and coherent today than it ever has been as a result, from icon themes to clipboards to compatibility between window managers to IPC to application notifications to application launching to multimedia to
The consistency was achieved not because we have single implementation - but because everybody has agreed what should be inside the implementation! Without previous duplication, without seeing the flipside of different design choices, reaching agreement wouldn't have been possible!
I work for commercial ISV. Believe me when I'm saying you from a decade of practical experience that "no duplication" doesn't mean "consistency" or "ease of development". Very very often decisions are rushed for marketing reasons and developers are stuck for years with a "committee design" nobody can change because nobody knows alternatives because we do not allow duplication.
The rule on staying alive as a forecaster is to give 'em a number or give 'em a date, but never give 'em both at once. -- Jane Bryant Quinn
