The Civ III/IV/V were indicatory of the direction they want to move the game: simplify, make it connected.
I'd say it is an achievement to have a Civ game play out in matter of hours. Marvel of game design. But that is also what made it shallow. When you start the game, you already know approximately how it is going to end. There are few surprises there.
AC to me was THE immersive game. You could play it short way - but that was boring. Or you could play it long way - and see your and game's limits. There are simply more possibilities in the AC, compared to the Civ. As time progresses, there are much more surprises in the game.
To me also it was the first game of the genre I could play on the highest difficulty level. All the info and numbers were there. Unlike the Civ where you have to guess and count number of the icons on the screen.
I had a number of friends who used Wine to run MSO, because their universities demanded papers in WinWord, e-mail in Outlook and IE for the intranet. That was quite some time ago now. All of the stuff worked pretty well, including 3rd party ActiveX plug-ins. But that's because MSO/IE are *the* software many use Wine for.
The catch is that Wine occasionally breaks stuff. For popular apps that might be not a problem - but for some obscure corpoware is. AFAIU regression testing is very minimal and done by volunteers - due to proprietary nature of the software Wine is used to run. The important bit is to stay with the version which works for you. If upgrade is needed, test new version thoroughly in advance.
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!?/s
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.NET to build their own applications, presumably because of poor performance.
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.
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.
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.
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.
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.
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 nice thing about Firefox is that even Nightly, after Australis has arrived, can be configured to look none-too-different than it did in Firefox 3.5.
Only the "look".
It is possible to make Firefox NNN to look like Fx 1/2/3, but in many places the *behavior* is hardcoded and impossible to change. E.g. activities vs. separate downloads/bookmarks/etc. Status bar add-on is also rather buggy, compared to its native counterpart of earlier Firefoxes. Ditto newer versions of the location bar.
On the other hand, getting a video card to work in linux last time I checked (granted a couple years) was a pain and you had to do backflips and jump through flaming hoops. I don't know enough about linux to get it working. I'm a cs guy for crying out loud...
Probably that was the problem?
If you have an nVidia card, for past 5+ years installation of the proprietary driver was a matter of a single click and a reboot. And that single click in a settings window called "Additional Drivers". Hard to miss if you trying to figure it out on your own.
Haven't tried ATI cards in recent years, but I'm pretty sure Ubuntu/derivatives does something about them too.
There were problems in the past with the very very recent nVidia cards, but they are updating drivers fairly quickly. (Though still slower than for Windows.)
Native vs. interpreted vs. JITed discussion is a moot. (They are all fast enough. On one side. On the other side, many code generators/translators add enough cruft for the code to often lose performance compared to the JITed/interpreted execution.)
The problem is with the libraries required by the run-time. One can compile Java application into a native app (using GCJ), but it is of little use since you still need the Java run-time. IOW, you are still poised to run into run-time deployment issues (version conflicts, local configuration, paths, etc).
Compilation to native code has value only if it allows you to create an application which doesn't have external dependencies or the external dependencies are very easy to manage.
AC successor? Very much doubt it.
The Civ III/IV/V were indicatory of the direction they want to move the game: simplify, make it connected.
I'd say it is an achievement to have a Civ game play out in matter of hours. Marvel of game design. But that is also what made it shallow. When you start the game, you already know approximately how it is going to end. There are few surprises there.
AC to me was THE immersive game. You could play it short way - but that was boring. Or you could play it long way - and see your and game's limits. There are simply more possibilities in the AC, compared to the Civ. As time progresses, there are much more surprises in the game.
To me also it was the first game of the genre I could play on the highest difficulty level. All the info and numbers were there. Unlike the Civ where you have to guess and count number of the icons on the screen.
So, either Colbert is a sell-out,
I take you don't watch the Colbert Report?
Colbert is openly a total sell-out. But he manages to make it funny for everybody's involved.
Never really liked the "late night" shows.
I had a number of friends who used Wine to run MSO, because their universities demanded papers in WinWord, e-mail in Outlook and IE for the intranet. That was quite some time ago now. All of the stuff worked pretty well, including 3rd party ActiveX plug-ins. But that's because MSO/IE are *the* software many use Wine for.
The catch is that Wine occasionally breaks stuff. For popular apps that might be not a problem - but for some obscure corpoware is. AFAIU regression testing is very minimal and done by volunteers - due to proprietary nature of the software Wine is used to run. The important bit is to stay with the version which works for you. If upgrade is needed, test new version thoroughly in advance.
800K PCs is a lot of stuff.
I wonder if anybody tried to calculate the costs of migrating that to a server farm with XP running in VMs?
If they use old hardware , then the RAM shouldn't be a problem.
If they use mostly the office software, then the CPU performance also shouldn't be a problem.
One can theoretically pack few dozens of those on a single blade.
Last time I checked, the MSO 2003/2007/etc (and old Windows software in general) runs very well under Wine.
Wine has problems with the newer software. But the old one runs fine.
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!? /s
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 .NET to build their own applications, presumably because of poor performance.
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 nice thing about Firefox is that even Nightly, after Australis has arrived, can be configured to look none-too-different than it did in Firefox 3.5.
Only the "look".
It is possible to make Firefox NNN to look like Fx 1/2/3, but in many places the *behavior* is hardcoded and impossible to change. E.g. activities vs. separate downloads/bookmarks/etc. Status bar add-on is also rather buggy, compared to its native counterpart of earlier Firefoxes. Ditto newer versions of the location bar.
Look - yes. Behavior - no.
On the other hand, getting a video card to work in linux last time I checked (granted a couple years) was a pain and you had to do backflips and jump through flaming hoops. I don't know enough about linux to get it working. I'm a cs guy for crying out loud...
Probably that was the problem?
If you have an nVidia card, for past 5+ years installation of the proprietary driver was a matter of a single click and a reboot. And that single click in a settings window called "Additional Drivers". Hard to miss if you trying to figure it out on your own.
Haven't tried ATI cards in recent years, but I'm pretty sure Ubuntu/derivatives does something about them too.
There were problems in the past with the very very recent nVidia cards, but they are updating drivers fairly quickly. (Though still slower than for Windows.)
Native vs. interpreted vs. JITed discussion is a moot. (They are all fast enough. On one side. On the other side, many code generators/translators add enough cruft for the code to often lose performance compared to the JITed/interpreted execution.)
The problem is with the libraries required by the run-time. One can compile Java application into a native app (using GCJ), but it is of little use since you still need the Java run-time. IOW, you are still poised to run into run-time deployment issues (version conflicts, local configuration, paths, etc).
Compilation to native code has value only if it allows you to create an application which doesn't have external dependencies or the external dependencies are very easy to manage.
Carpooling typically covers only the city itself.
If you live in the city - then you normally take the mass transit.
If you live outside the city, then you pick up your carpooling friends outside the city.