Excel and Word for mac are still Power PC version so they need to run via Rosetta which will slow down the resusults running XP will actually have a better performance for the Test.
First, do you actually know this? Have you tested it?
Second, why are you limiting this to Excel and Word? Why not iWork on the Mac?
Also they didn't run the normal benchmark software as well. Knowing quite well the new system will eat its lunch.
Yeah, because how fast you can calculate a bunch of digits of Pi has a real impact on productivity.
Also they are using different versions of software.
No shit, Sherlock. The whole point is that modern software is bloated.
Bootup Speet is important espectially back in the 80's where people turned off their computers when they were done, and people still do that today. So bootup time is quite useful in measuring productivity.
I don't think so. For a desktop office machine? In 1980, you turn it on, wait a bit, and it's ready. Today, you turn it on, get coffee, come back, and it's ready.
Really, you're losing two minutes of productivity, assuming you wouldn't have gotten the coffee later anyway. Maybe the caffeine will make you more productive anyway.
In Linux if you misconfigure say sendmail in Red Hat when you boot up you are waiting for minutes for it to load and fail. Making Linux Boot time painfully slow.
First, who the hell uses sendmail anymore, when we have Qmail, Exim, and (my favorite) Postfix?
Second, how does a failure make Linux boot any slower? It generally makes mine faster, unless it causes the whole boot to fail, in which case I'm hosed anyway.
This effects productivity (say your job is to insure Sendmail works properly at bootup).
On a modern system, you can easily reload a daemon, including Sendmail, without waiting for a reboot. You generally do this with the init script, typically something like "/etc/init.d/postfix stop &&/etc/init.d/postfix start" -- which is exactly what would be run by init when you reboot. The only real way a reboot would not start it properly if it starts for you here is if you somehow don't have it configured to start on boot, or if you have it configured to start in the wrong order -- but on a Debian-based system, installing most daemons from the package manager will automatically add them to your boot runlevels, in the right order.
In fact, it's entirely possible you could just do "apt-get install postfix", answer a few questions, and leave it in its default configuration. The package manager will automatically start it when you're done configuring, and also automatically set it to start on boot.
In other words, on a modern system, you kind of have to be trying to screw up the boot process.
For windows reboots are frequent when you have updates so you are working on you job and you get an automatic update you need to reboot and wait 2 minutes when you get everything back you need to refresh were you left off.
Yeah, I hate this too. Fortunately, Windows updates which require a reboot seem about as rare these days as Linux kernel updates (the only time you really need to reboot Linux), which is maybe once or twice a month, at most.
Actually, this doesn't really count as a productivity hit, when you think about it. There's nothing stopping you from putting off the updates until the end of the day, then shutting down your computer the way you do every day. When you next boot it, you'll have the updates properly installed. Worst-case, you'll have to get a donut with that coffee.
The point of the article is that as computers get faster the software get proportionally slower so you tend to get a 0 net gain in productivity in the common jobs you do on your syste
I really don't see the amount of time for an app to open as a major motivator, either. It does help me a bit when comparing two mostly-equivalent apps (KWord vs OOWriter), but other than that, I don't launch apps very often. Modern machines come loaded with WAY more RAM than anyone needs. Even ignoring that, with intelligently-written programs and decent memory management, having 20 or 30 extra processes sitting around in swap doesn't hurt anything.
I see app launch time as adding to the boot time of the system, not the launch time of that particular app.
That, and I'm on a RAID 0 with 2 gigs of RAM. Launch time for just about anything is just about twice as fast as anyone with a single hard disk.
I'd argue, though, that performance is a secondary concern for most people and most uses of a computer. Stability, utility, usability, security, and maintainability (not at all in that order) should be primary concerns. Telnet is faster and easier to use than ssh, no doubt, but the difference is not noticeable, and even if it was, I am not willing to trade security for speed and usability -- at least, not at that level. KWord is slower to start than vim, but since I don't know TeX and don't feel like learning, KWord is how I write things I intend to print.
There are native Linux/GL ports of every Unreal Tournament, and the original Unreal (apparently ported to the UT engine). It's true, UT2k4 had Direct3D and OpenGL renderers, using the d3d ones by default on Windows, but they do support OpenGL, and provide probably 95% of the functionality right away, and the other 5% (stencil shadows, for example) in patches.
I don't know if Carmack is going OpenGL, but I do know that if he does, it will force the API to keep pace. That's what happened with Doom 3 -- it is OpenGL only, and both vendors rushed to release updated drivers with better OpenGL support in time for the Doom 3 release. Others do the same thing, too -- Half-Life 2 and DirectX.
Erm... One of those examples had xml, and I forgot to escape it for the web... that should be
xml = new SomeParser('<a><b/><c>hi<d>there</d></c></a>')
Also, the example's a bit contrived, given that real XML parsing in Ruby is usually handled by REXML, which does do all the parsing upfront (as far as I know; there's enough abstraction that it might not), and stores it in not just arrays, but recursive object structures that more closely reflect what XML looks like.
I would say that the first mistake is using C++ at all for "Kill Bad Aliens". Even coding it in Ruby would probably be fast enough for most machines, though I'd probably use Python or something.
The second problem here is, why would you have a separate type for counter_type and limit_type? I guess I can imagine something like this happening in a larger context, but it seems like the above should probably be the same type.
As for what I'd do to prevent the above, I'd use unit tests. That way, I'd know exactly where the infinite loop was, as soon as I changed the type of either limit_type or counter_type, and it probably would not take me very long to figure it out from there.
I understand that a simple "for" loop may be comforting, I grew up with them too. But most of the time, there's no reason for it, and you'd be better served with a Ruby-like iterator. Something like:
max_counts=65537 max_counts.times { |i|
puts i if (i%128 == 0) }
That's assuming you actually need to count to 65537 and have i in the first place. Usually, you have a for loop because you need to iterate over something, which means you'd be better served with something like a foreach loop:
my_stuff = ['one', 'two', 3, 0.4, SomeObject foo, somevar, and, so, on] my_stuff.each { |x|
puts x }
Of course, the especially cool part about Ruby is that I'm ignoring types here entirely in the values I'm printing. In general, all I need to be able to print an object is for it to have a to_s method, allowing it to be implicitly converted to a string -- which I think is a lot nicer than overloading bitwise operators, the way iostream does.
But you can see here, even if I was concerned about integer types in Ruby -- and I'm not, Ruby seems to automatically flip over to the BigNum library as needed -- the latter form avoids even needing a counter, or assuming that what I'm iterating over looks like an array at all. It's usually much more efficient to implement one "each" method than to overload [] for strange types. Consider something like a parser:
xml = new SomeParser('hithere') xml.each_token( |x|
do_something_with(x) }
I'd say the majority of problems match much better onto something like that, where it can simply walk through the string, parsing as you go, than something like this:
for (i=0; i
In that example, it now has to parse xml's string entirely at least once to get the number of tokens, and it'd really be better off just caching it as an array, since we could theoretically want random access to it.
Now, there's nothing stopping you from implementing all of the above, and more, including the traditional way to do it:
while (defined(t = xml.next_token))
do_something_with(t) end
But there's another disadvantage for simply asking for next_token. You now have to remember to reset it somehow, otherwise the next thing to want to iterate through is going to get a big fat NULL.
Also, you've lost something else: "each" is generic. There are standard library functions, and certainly user libraries, which know how to use each. Even if you can't think of a use for that, it helps that you already know how to use foo.each, even if it's something weird like foo.each_token. And maybe it's just me, but it looks a LOT clearer than certain other libraries I've used which pass around callbacks, even if it's effectively doing the exact same thing.
Despite the fact that most of my examples are in Ruby, I really don't like Ruby. I think it's like Perl, but with even more emphasis on strings, and it looks like it will be dog-slow for a very long time. But it does make for very quick hacks, and it's certainly sufficient for a Kill Bad Aliens game.
True, but than add the cost off the admin setting the whole thing up. Add to cost of the needed spare parts and add the cost of replacement (both in labor and parts) of failing components.
I'm very, very skeptical that you could get away without either, in a company of any size which can afford to spend $50k on a single box. Certainly, I'd think twice about building a business environment around a single box with no hot spare which probably costs at least half of a year's salary of an admin anyway.
I'm also getting really tired of bug reports from Gentoo users. They report my app is broken, when it appears they managed to compile KDElibs without SSL, or use a bleeding edge build system which is not supported by stable KDE releases.
If they managed to compile KDElibs without SSL, and if that's something KDElibs allows you to do (easily), then it is not their fault for custom-compiling something, it is your fault for not specifying SSL as a dependency.
As for the bleeding-edge build system, I can understand your frustration, but if (emphasis on if) KDE is moving towards that bleeding-edge system -- if it's actually on the roadmap -- then you should be putting it in your own bleeding-edge builds, too. I hate when we get things like upstart (in Ubuntu Edgy and Feisty) which has all these amazing capabilities, but ends up basically being used for launching runlevels because no developers actually wrote upstart-specific init scripts. (Which is one nice thing I can say for Gentoo; they do tend to always write Gentoo-specific init scripts.)
Now, I don't use Gentoo anymore, don't really like it for a couple of reasons, but if there's anything I hate about Gentoo bug reports, it's the ones I send to the Gentoo guys that get ignored for years at a time.
Example from TFA:// move all the aliens for (short i = 0; I < MAX_NUM_ALIENS; i++)
if (aliens[i].exists())// this alien currently exist?
aliens[i].move_it();
I realize that for the game he's currently got, a short may be sufficient. But it's not hard to imagine a later version supporting swarms of aliens, with individually animated tentacles (each of which might count as an alien in that array), etc etc.
Personally, when dealing with code written in a statically typed language, I like to make sure I #define every single type I'm using, even if it's something simple like a short, because you never know when you'll have to change it. Probably makes it easier to go 64-bit clean, too, but in any case, it's something I learned from the Linux kernel, and it seems to just make a lot of sense.
He also didn't seem to be using a particularly object-oriented style, for a so-called C++ programmer:
As others have pointed out, that's a damned weird coding style. But whatever.
The point is, as he says:
The problem here is that we probably don't want the scoreboard to flash with pretty colors when the number displayed doesn't change.
And of course, what he's likely missing here is, we probably don't want the score to ever be updated without making the screen flash with pretty colors, either. So where is that function? Looks global, but it's been awhile since I've done C++. But if it is global, that implies that something else, somewhere else, might update the score for no apparent reason, and neglect to call make_sparkles_on_score().
And also: What else might we want to do with the score? Is the score the only thing we want to display and change, anyway? (Maybe we want to implement health later, or some other statistic that should be up there and flash some animation when updated.)
It seems to me, the obvious thing to do here is create a class for score, and override the relevant mathematical operators. (One of the few legitimate uses for operator overloading, but I digress...) Maybe it's just me, but saying change_score(10) seems a lot less intuitive than score+=10.
It would also solve the problem of that explicit short. I don't suppose anyone would ever want to change the score by more than 65,535? Wait, it's a signed short, so half that....And why is he accepting a signed short, and then checking whether it's positive? (And why even care whether the score goes up or down, on that level -- I don't think it's the job of the score change itself to do that check, you'd do that after any calculation where you want to make sure it's a positive change in score.)
I admit some of these are a matter of taste -- some people don't like object-oriented programming. But I do think some of them are fairly obvious, almost instinctive for me.
It's great that you have 20TB of storage, but what if you have dozens of database servers concurrently slamming different parts of that 20TB with wildly random I/O?
I would think that in that situation, more disks would be better than fewer, individually faster disks. Kind of like how if you're doing much concurrently, a dual-core machine with 2ghz/core is faster than one 3ghz machine (even if it was all about ghz).
That said, I'm no expert, and I haven't done the benchmarks. My biggest array is half a terabyte.
Or, in other words, hell yes, large PC clusters can obsolete mainframes. And yes, it depends how you use it -- or, in other words, if your application actually can support a large PC cluster instead of a mainframe.
It seems to me that even if the entire setup is prone to failure, all you really need is a gigabit crossover or two running to an identical setup. I don't know if ZFS does anything like this, but I can think of at least one way to make it work on Linux: DRBD + OCFS2 + heartbeat. If you're smart, you can even do some load balancing, at least until one of them fails -- and when that happens, the other should be able to take over very quickly, if not instantly -- Linux heartbeat means it would simply takeover the other machine's IP and start its services.
So, that's $6k total instead of $3k.
The one problem I have with OCFS2 is that when it fences a system, it tends to either bring the whole thing down (kernel panic), or in newer versions, give you the option of forceably rebooting instead. This killed it for a project I was working on, where one of the machines had other mission-critical systems running that were not on the OCFS2, and thus, it seemed retarded to panic and bring down everything else too.
So if that's your problem, you can always build a third, identical system to run the other stuff on. $9k.
Even if you figure another $1k for random stuff, like maybe a LOT of gigabit crossovers, or 10gig fiber, or something, that's still a fifth of the cost of the "business-grade" or whatever else he was considering. Even assuming the worst-case scenario, where the homebrew system costs a lot more to maintain (even electricity and cooling, maybe), how long will it take for it to cost another $40k? And this way, you have an ENTIRELY redundant system -- the only way you lose it is if, say, the whole building blows up.
I mean, I sort of agree that you get what you pay for. But when the difference in price is that much, the only way it's ever worth it is if there's really great support with the high-end package. And is it $40k worth of support? If not, I imagine this guy could put together a company selling little $3k, $6k, and $10k systems for $20k each (including support), shaving off $30k even for the most paranoid.
And all of that is pretending you're right about the cheap consumer-grade hardware actually being less reliable.
Some of these issues looked familiar, so I thought I'd do a basic comparison:
Reiser4 had the same problems with fsync -- basically, fsync called sync. This was because their sync is actually a damned good idea -- wait till you have to (memory pressure, sync call, whatever), then shove the entire tree that you're about to write as far left as it can go before writing. This meant awesome small-file performance -- as long as you have enough RAM, it's like working off a ramdisk, and when you flush, it packs them just about as tightly as you can with a filesystem. It also meant far less fragmentation -- allocate-on-flush, like XFS, but given a gig or two of RAM, a flush wasn't often.
The downside: Packing files that tightly is going to fragment more in the long run. This is why it's common practice for defragmenters to insert "air holes". Also, the complexity of the sync process is probably why fsync sucked so much. (I wouldn't mind so much if it was smarter -- maybe sync a single file, but add any small files to make sure you fill up a block -- but syncing EVERYTHING was a mistake, or just plain lazy.) Worse, it causes reliability problems -- unless you sync (or fsync), you have no idea if your data will be written now, or two hours from now, or never (given enough RAM).
(ZFS probably isn't as bad, given it's probably much easier to slice your storage up into smaller filesystems, one per task. But it's a valid gotcha -- without knowing that, I'd have just thrown most things into the same huge filesystem.)
There's another problem with reliability: Basically, every fast journalling filesystem nowadays is going to do out-of-order write operations. Entirely too many hacks depend on ordered writes (ext3 default, I think) for reliability, because they use a simple scheme for file updating: Write to a new temporary file, then rename it on top of the old file. The problem is, with out-of-order writes, it could do the rename before writing the data, giving you a corrupt temporary file in place of the "real" one, and no way to go back, even if the rename is atomic. The only way to get around this with traditional UNIX semantics is to stick to ordered writes, or do an fsync before each rename, killing performance.
I think the POSIX filesystem API is too simplistic and low-level to do this properly. On ordered filesystems, tempfile-then-rename does the Right Thing -- either everything gets written to disk properly, or not enough to hurt anything. Renames are generally atomic on journalled filesystems, so either you have the new file there after a crash, or you simply delete the tempfile. And there's no need to sync, especially if you're doing hundreds or thousands of these at once, as part of some larger operation. Often, it's not like this is crucial data that you need to be flushed out to disk RIGHT NOW, you just need to make sure that when it does get flushed, it's in the right order. You can do a sync call after the last of them is done.
Problem is, there are tons of other write operations for which it makes a lot of sense to reorder things. In fact, some disks do that on a hardware level, intentionally -- nvidia calls it "native command queuing". Using "ordered mode" is just another hack, and its drawback is slowing down absolutely every operation just so the critical ones will work. But so many are critical, when you think about it -- doesn't vim use the same trick?
What's needed is a transaction API -- yet another good idea that was planned for someday, maybe, in Reiser4. After all, single filesystem-metadata-level operations are generally guaranteed atomic, so I would guess most filesystems are able to handle complex transactions -- we just need a way for the program to specify it.
The fragmentation issue I see as a simple tradeoff: Packing stuff tightly saves you space and gives you performance, but increases fragmentation. Running a defragger (or "repacker") every once in awhile would have been nice. Problem is, they never got one written. Common UNIX (and Mac) philosoph
There's already an inconsistency there ("Unlimited" local calls really is unlimited, but "Unlimited" Internet access very rarely is). But even ignoring that, law should be close to ethics. That's why it exists in the first place.
Or better, either advertise 100k or build the other 180 megs you're charging us for.
If you have 20 megs upstream, you get to sell 20 megs downstream, unfiltered, unshaped, un-messed-with. Then we get to put the whole "net neutrality" debate behind us, among other things.
The government is what protects us from false advertising. Net neutrality, in particular, should be required by anything that wants to claim it is an ISP -- otherwise, it should not be able to call it "Internet access".
Also, remember that plenty of ISPs receive government funding to build the network infrastructure (which they haven't been doing), and often, there's only one or two in an area. So, everything you just suggested is something customers should do, but none of it excuses asshatry from any ISP, for any reason.
That still seems intentionally misleading, given the "Up to" implies different plans you could buy, like 512Kb, 2Mb, 6Mb, and 12Mb. I bet when you get right down to it, your bill is for 12Mb service, not "Up to 12Mb".
Besides, in what other industry is this OK? When I buy phone service with unlimited local calls, it doesn't say "Up to unlimited local calls" or "Unlimited local calls that might sound like crap". And when I don't have local service, I complain to my phone company, simple as that.
And anyway, if that did work for covering asses so well, couldn't I sell dialup service as "Up to 1Gb!" Sure, it'll never get there, never could, but I can just claim I never guaranteed any amount of bandwidth. I can then go on to say that you should have read the fine print on "Unlimited hours" and go disconnect you for the rest of the day, while laughing maniacally and rolling in a pile of money.
A minor correction to that statement: They advertise unlimited data transfer. The bandwidth is limited and is -always- advertised as such.
Not true. In fact, the only place where I see bandwidth advertised clearly and truthfully is in web hosting, where you simply buy a fixed amount of data transfer, usually on a 10 or 100 mbit pipe. No way you'll saturate the thing with whatever you're paying for monthly, but at least you know exactly what you're paying for.
My ISP, and maybe your ISP, are likely exceptions. I pretty much have 1 Mbit, pretty much all the time. I can usually saturate it for weeks at a time with BitTorrent, and the worst I ever slow down to is half.
But most ISPs aren't as honest. They sell "burst bandwidth", which is their way of weaseling out of any responsibility. They'll claim "UNLIMITED", but what they mean by that is, you can stay connected as long as you want, and transfer as much as you can, without paying extra. They don't mean that you'll be able to saturate the 6 Mbits 24/7, unless no one else is connected.
There isn't enough roadway for everyone in New York to drive their car at the same time.
And there are occasionally traffic jams, which suggests the infrastructure there could be improved. But whatever, I'm not paying a monthly fee specifically for the purpose of driving on roads in New York. You could argue that I'm paying my taxes there (I live in Iowa, but that's not the point), but the tax forms don't come with a glossy flier with big bold letters saying "UNLIMITED driving!"
There aren't enough cell phone towers for everyone to talk on the phone at the same time. I'm sure there are plenty more examples.
I'm not sure how it works with cell phone towers, but I honestly cannot think of anything else that is sold by claiming you get UNLIMITED service, and then not delivering. The only thing that comes close is overbooking, which seems deceptive to me anyway.
Someone recently found out about this situation and suddenly thinks they know more than everyone else in the industry, and decided to tell us the sky is falling.
More likely, us geeks have known about this all along, and any publicity about the situation might help encourage ISPs to go light up that dark fiber, research that wireless, and actually deliver the bandwidth they've been selling us. It's kind of like, most articles about DRM read to Slashdotters as "Well, duh!", but not everyone even knows DRM exists.
Yes, I know what AJAX stands for. However, the majority of it is something called DHTML (Dynamic HTML), which was simply JavaScript + the HTML DOM.
In fact, most of "AJAX" today is simply DHTML tricks that people were using years ago, but somewhere along the way, JavaScript became something to drive popup ads, and people started thinking you needed Flash to make a dynamic-looking website.
Even the 'X' in AJAX is optional -- plenty of people use JSON instead of XML for their AJAX apps. And the 'A' part? Firefox is certainly threaded, and among other things, it will download a new version of itself in the background (on Windows, at least) and prompt you when it's ready to be installed.
So, I would have called it DHTML, but AJAX is catchier, and it's what people know now. (Besides, it's not really HTML, it's XUL...)
I read Schneier's page because I respect the guy, and I figured he'd know what he was talking about. It already seemed trivially vulnerable to a man-in-the-middle attack, but I wanted to see if I was the only one.
Looks like I'm right:
Even more basic: It's vulnerable to man-in-the-middle attacks. Someone who can intercept and modify messages in transit can break the security. This means you need an authenticated channel to make it work -- a link that guarantees you're talking to the person you think you're talking to. How often in the real world do we have a wire that is authenticated but not confidential? Not very often.
He actually details a few more problems:
For those keeping score, that's four practical problems: It's only link encryption and not end-to-end, it's bandwidth-limited (but may be enough for key exchange), it works best for short ranges and it requires authentication to make it work. I can envision some specialized circumstances where this might be useful, but they're few and far between.
But then, I guess it's the best we've got:
But quantum key distributions have the same problems. Basically, if Kish's scheme is secure, it's superior to quantum communications in every respect: price, maintenance, speed, vibration, thermal resistance and so on.
It's called Gecko. Most of Firefox is written in either cross-platform C++, or XUL/JavaScript, which makes it probably the only browser to itself be an AJAX application. (And Mozilla did the same thing long before AJAX was even a word.)
Also, there aren't many virtual machines out there. I agree, we don't need this one -- x86 is just a retarded target for this sort of virtualization -- but even if we count Java, Mono, Parrot, Python, Erlang, and XUL, that's still not a lot of RAM by today's standards. You'd lose more by having to use different GUI toolkits in your C++ app -- one uses wxwindows, one uses GTK+, one uses QT, one uses TK, maybe one even uses Motif or straight OpenGL. And that's just the GUI -- there are all kinds of cross-platform C++ libraries, some (I'd argue) with more overhead than a VM.
Given the choice between running a bunch of GUI toolkits running recompiled C++ code, and a bunch of VMs running on the same GUI toolkit, I'd much prefer the latter.
Also, VMs can theoretically perform better than C, so I'm only counting RAM usage required by different VMs as "overhead".
Great. So why are you writing a cross-platform app that relies on specific hardware or OS features?
Also, it seems much simpler and more elegant to take whatever features you need and abstract them away in a cross-platform library (like QT) rather than virtualization/emulation.
The most accepted way for this is to develop a framework with WxWidgets. But what if you don't like the framework? What if you need a different framework? What if your language is not supported by the framework?
Then you use a different framework. There are at least three or four out there.
A lot of people complain about cross-platform frameworks not feeling native, especially on OS X. In fact, that's the main argument against them. But I fail to see how forcing it to simply be a Linux application and then virtualizing it anywhere improves the situation.
If one application requires a later version of a library than another is compatible with, you can't run them both easily on the same machine.
Well, if the one that requires the earlier version isn't updated quickly enough, and if there's only one of it, then... well, it's not particularly easy, but it's not particularly hard, either. Simply install multiple copies of the library. If the package manager doesn't support it, then manually install one of them in a place outside of the normal library paths, and use things like LD_PRELOAD to force the troublesome app to use your library.
In fact, commercial games have used this approach on Linux for ages.
If you can get my mom to understand that sentence, I will pay you $500.
Believe it or not, this isn't as difficult as it's made out to be. The biggest barrier would be convincing your mother that she should know, rather than having her simply say "This is too complicated!" at the first hint that she might actually have to learn something.
But seriously, if you give me a half hour or so with your mother, I will be able to get her to understand it, so $500 is a pretty generous offer. And I could use the money now. Want to send me her email address or something?
It could be a very simple old idea used in an ingenious way to be a very useful tool for the masses.
I don't think it's particularly ingenious, either.
Like this, they aren't hiding that they're kind of copying what Java does.
Except Java does it better. I don't even like Java, but I have to admit, it does it better.
But, you know, if it was such an easy engineering task, why haven't you done it?
Because it's an ugly, ugly hack -- I'd much rather do something useful, like, say, improve one of the real "compile-once, run anywhere" platforms, or improve package management to where such things aren't needed. We're already mostly there anyway -- no matter what the physical architecture, I can generally easily find a GUI package manager for my distro. If I choose the same distro on all platforms, it'll even look similar. And if I'm on something other than Linux, I simply download the binary for my OS. Even if I'm completely clueless, I can simply browse to the program's website, and it can auto-detect my OS and suggest a version to download -- Firefox does this, for example.
Bonus: It now really does run anywhere, not just "any x86 processor". Yes, I realize you can do emulation as well as virtualization, but that's just retarded -- why would I want to lose at least 50% of the speed because your mother is too lazy to download the right version for her platform? With actual binaries, I can get true 64-bit clean versions, on x86_64 or ppc_64, or even ARM binaries... Can you imagine trying to run Linux inside an x86 emulator on a PocketPC? No wonder so many cell phones use Java instead.
Also? Because it's already been done. Depending on the implementation, it's either called "user-mode Linux" (I am not sure if this runs on OSes other than Linux, but I imagine it'd run on OS X) or Qemu.
Ordinarily, I wouldn't bother criticizing them, but I think what they're doing is actually harmful. I would much rather have something written in Java, or cross-platform with QT or wxwindows, than something that's x86 Linux only because someone told them x86 Linux was "compile-once, run anywhere".
Slashdot Mirror
First, do you actually know this? Have you tested it?
Second, why are you limiting this to Excel and Word? Why not iWork on the Mac?
Yeah, because how fast you can calculate a bunch of digits of Pi has a real impact on productivity.
No shit, Sherlock. The whole point is that modern software is bloated.
I don't think so. For a desktop office machine? In 1980, you turn it on, wait a bit, and it's ready. Today, you turn it on, get coffee, come back, and it's ready.
Really, you're losing two minutes of productivity, assuming you wouldn't have gotten the coffee later anyway. Maybe the caffeine will make you more productive anyway.
First, who the hell uses sendmail anymore, when we have Qmail, Exim, and (my favorite) Postfix?
Second, how does a failure make Linux boot any slower? It generally makes mine faster, unless it causes the whole boot to fail, in which case I'm hosed anyway.
On a modern system, you can easily reload a daemon, including Sendmail, without waiting for a reboot. You generally do this with the init script, typically something like "/etc/init.d/postfix stop && /etc/init.d/postfix start" -- which is exactly what would be run by init when you reboot. The only real way a reboot would not start it properly if it starts for you here is if you somehow don't have it configured to start on boot, or if you have it configured to start in the wrong order -- but on a Debian-based system, installing most daemons from the package manager will automatically add them to your boot runlevels, in the right order.
In fact, it's entirely possible you could just do "apt-get install postfix", answer a few questions, and leave it in its default configuration. The package manager will automatically start it when you're done configuring, and also automatically set it to start on boot.
In other words, on a modern system, you kind of have to be trying to screw up the boot process.
Yeah, I hate this too. Fortunately, Windows updates which require a reboot seem about as rare these days as Linux kernel updates (the only time you really need to reboot Linux), which is maybe once or twice a month, at most.
Actually, this doesn't really count as a productivity hit, when you think about it. There's nothing stopping you from putting off the updates until the end of the day, then shutting down your computer the way you do every day. When you next boot it, you'll have the updates properly installed. Worst-case, you'll have to get a donut with that coffee.
I really don't see the amount of time for an app to open as a major motivator, either. It does help me a bit when comparing two mostly-equivalent apps (KWord vs OOWriter), but other than that, I don't launch apps very often. Modern machines come loaded with WAY more RAM than anyone needs. Even ignoring that, with intelligently-written programs and decent memory management, having 20 or 30 extra processes sitting around in swap doesn't hurt anything.
I see app launch time as adding to the boot time of the system, not the launch time of that particular app.
That, and I'm on a RAID 0 with 2 gigs of RAM. Launch time for just about anything is just about twice as fast as anyone with a single hard disk.
I'd argue, though, that performance is a secondary concern for most people and most uses of a computer. Stability, utility, usability, security, and maintainability (not at all in that order) should be primary concerns. Telnet is faster and easier to use than ssh, no doubt, but the difference is not noticeable, and even if it was, I am not willing to trade security for speed and usability -- at least, not at that level. KWord is slower to start than vim, but since I don't know TeX and don't feel like learning, KWord is how I write things I intend to print.
There are native Linux/GL ports of every Unreal Tournament, and the original Unreal (apparently ported to the UT engine). It's true, UT2k4 had Direct3D and OpenGL renderers, using the d3d ones by default on Windows, but they do support OpenGL, and provide probably 95% of the functionality right away, and the other 5% (stencil shadows, for example) in patches.
I don't know if Carmack is going OpenGL, but I do know that if he does, it will force the API to keep pace. That's what happened with Doom 3 -- it is OpenGL only, and both vendors rushed to release updated drivers with better OpenGL support in time for the Doom 3 release. Others do the same thing, too -- Half-Life 2 and DirectX.
Erm... One of those examples had xml, and I forgot to escape it for the web... that should be
/><c>hi<d>there</d></c></a>')
xml = new SomeParser('<a><b
Also, the example's a bit contrived, given that real XML parsing in Ruby is usually handled by REXML, which does do all the parsing upfront (as far as I know; there's enough abstraction that it might not), and stores it in not just arrays, but recursive object structures that more closely reflect what XML looks like.
I would say that the first mistake is using C++ at all for "Kill Bad Aliens". Even coding it in Ruby would probably be fast enough for most machines, though I'd probably use Python or something.
The second problem here is, why would you have a separate type for counter_type and limit_type? I guess I can imagine something like this happening in a larger context, but it seems like the above should probably be the same type.
As for what I'd do to prevent the above, I'd use unit tests. That way, I'd know exactly where the infinite loop was, as soon as I changed the type of either limit_type or counter_type, and it probably would not take me very long to figure it out from there.
I understand that a simple "for" loop may be comforting, I grew up with them too. But most of the time, there's no reason for it, and you'd be better served with a Ruby-like iterator. Something like:
max_counts=65537
max_counts.times { |i|
puts i if (i%128 == 0)
}
That's assuming you actually need to count to 65537 and have i in the first place. Usually, you have a for loop because you need to iterate over something, which means you'd be better served with something like a foreach loop:
my_stuff = ['one', 'two', 3, 0.4, SomeObject foo, somevar, and, so, on]
my_stuff.each { |x|
puts x
}
Of course, the especially cool part about Ruby is that I'm ignoring types here entirely in the values I'm printing. In general, all I need to be able to print an object is for it to have a to_s method, allowing it to be implicitly converted to a string -- which I think is a lot nicer than overloading bitwise operators, the way iostream does.
But you can see here, even if I was concerned about integer types in Ruby -- and I'm not, Ruby seems to automatically flip over to the BigNum library as needed -- the latter form avoids even needing a counter, or assuming that what I'm iterating over looks like an array at all. It's usually much more efficient to implement one "each" method than to overload [] for strange types. Consider something like a parser:
xml = new SomeParser('hithere')
xml.each_token( |x|
do_something_with(x)
}
I'd say the majority of problems match much better onto something like that, where it can simply walk through the string, parsing as you go, than something like this:
for (i=0; i
In that example, it now has to parse xml's string entirely at least once to get the number of tokens, and it'd really be better off just caching it as an array, since we could theoretically want random access to it.
Now, there's nothing stopping you from implementing all of the above, and more, including the traditional way to do it:
while (defined(t = xml.next_token))
do_something_with(t)
end
But there's another disadvantage for simply asking for next_token. You now have to remember to reset it somehow, otherwise the next thing to want to iterate through is going to get a big fat NULL.
Also, you've lost something else: "each" is generic. There are standard library functions, and certainly user libraries, which know how to use each. Even if you can't think of a use for that, it helps that you already know how to use foo.each, even if it's something weird like foo.each_token. And maybe it's just me, but it looks a LOT clearer than certain other libraries I've used which pass around callbacks, even if it's effectively doing the exact same thing.
Despite the fact that most of my examples are in Ruby, I really don't like Ruby. I think it's like Perl, but with even more emphasis on strings, and it looks like it will be dog-slow for a very long time. But it does make for very quick hacks, and it's certainly sufficient for a Kill Bad Aliens game.
I'm very, very skeptical that you could get away without either, in a company of any size which can afford to spend $50k on a single box. Certainly, I'd think twice about building a business environment around a single box with no hot spare which probably costs at least half of a year's salary of an admin anyway.
If they managed to compile KDElibs without SSL, and if that's something KDElibs allows you to do (easily), then it is not their fault for custom-compiling something, it is your fault for not specifying SSL as a dependency.
As for the bleeding-edge build system, I can understand your frustration, but if (emphasis on if) KDE is moving towards that bleeding-edge system -- if it's actually on the roadmap -- then you should be putting it in your own bleeding-edge builds, too. I hate when we get things like upstart (in Ubuntu Edgy and Feisty) which has all these amazing capabilities, but ends up basically being used for launching runlevels because no developers actually wrote upstart-specific init scripts. (Which is one nice thing I can say for Gentoo; they do tend to always write Gentoo-specific init scripts.)
Now, I don't use Gentoo anymore, don't really like it for a couple of reasons, but if there's anything I hate about Gentoo bug reports, it's the ones I send to the Gentoo guys that get ignored for years at a time.
That's 3-5 hours less than a laptop I had a few years ago. And that was actually a laptop, 15 gig hard drive and all...
for (short i = 0; I < MAX_NUM_ALIENS; i++)
if (aliens[i].exists())
aliens[i].move_it();
I realize that for the game he's currently got, a short may be sufficient. But it's not hard to imagine a later version supporting swarms of aliens, with individually animated tentacles (each of which might count as an alien in that array), etc etc.
Personally, when dealing with code written in a statically typed language, I like to make sure I #define every single type I'm using, even if it's something simple like a short, because you never know when you'll have to change it. Probably makes it easier to go 64-bit clean, too, but in any case, it's something I learned from the Linux kernel, and it seems to just make a lot of sense.
He also didn't seem to be using a particularly object-oriented style, for a so-called C++ programmer:
Void change_score(short num_points)
{
score += num_points;
make_sparkles_on_score();
}
As others have pointed out, that's a damned weird coding style. But whatever.
The point is, as he says:And of course, what he's likely missing here is, we probably don't want the score to ever be updated without making the screen flash with pretty colors, either. So where is that function? Looks global, but it's been awhile since I've done C++. But if it is global, that implies that something else, somewhere else, might update the score for no apparent reason, and neglect to call make_sparkles_on_score().
And also: What else might we want to do with the score? Is the score the only thing we want to display and change, anyway? (Maybe we want to implement health later, or some other statistic that should be up there and flash some animation when updated.)
It seems to me, the obvious thing to do here is create a class for score, and override the relevant mathematical operators. (One of the few legitimate uses for operator overloading, but I digress...) Maybe it's just me, but saying change_score(10) seems a lot less intuitive than score+=10.
It would also solve the problem of that explicit short. I don't suppose anyone would ever want to change the score by more than 65,535? Wait, it's a signed short, so half that.
I admit some of these are a matter of taste -- some people don't like object-oriented programming. But I do think some of them are fairly obvious, almost instinctive for me.
I would think that in that situation, more disks would be better than fewer, individually faster disks. Kind of like how if you're doing much concurrently, a dual-core machine with 2ghz/core is faster than one 3ghz machine (even if it was all about ghz).
That said, I'm no expert, and I haven't done the benchmarks. My biggest array is half a terabyte.
Or, in other words, hell yes, large PC clusters can obsolete mainframes. And yes, it depends how you use it -- or, in other words, if your application actually can support a large PC cluster instead of a mainframe.
It seems to me that even if the entire setup is prone to failure, all you really need is a gigabit crossover or two running to an identical setup. I don't know if ZFS does anything like this, but I can think of at least one way to make it work on Linux: DRBD + OCFS2 + heartbeat. If you're smart, you can even do some load balancing, at least until one of them fails -- and when that happens, the other should be able to take over very quickly, if not instantly -- Linux heartbeat means it would simply takeover the other machine's IP and start its services.
So, that's $6k total instead of $3k.
The one problem I have with OCFS2 is that when it fences a system, it tends to either bring the whole thing down (kernel panic), or in newer versions, give you the option of forceably rebooting instead. This killed it for a project I was working on, where one of the machines had other mission-critical systems running that were not on the OCFS2, and thus, it seemed retarded to panic and bring down everything else too.
So if that's your problem, you can always build a third, identical system to run the other stuff on. $9k.
Even if you figure another $1k for random stuff, like maybe a LOT of gigabit crossovers, or 10gig fiber, or something, that's still a fifth of the cost of the "business-grade" or whatever else he was considering. Even assuming the worst-case scenario, where the homebrew system costs a lot more to maintain (even electricity and cooling, maybe), how long will it take for it to cost another $40k? And this way, you have an ENTIRELY redundant system -- the only way you lose it is if, say, the whole building blows up.
I mean, I sort of agree that you get what you pay for. But when the difference in price is that much, the only way it's ever worth it is if there's really great support with the high-end package. And is it $40k worth of support? If not, I imagine this guy could put together a company selling little $3k, $6k, and $10k systems for $20k each (including support), shaving off $30k even for the most paranoid.
And all of that is pretending you're right about the cheap consumer-grade hardware actually being less reliable.
Some of these issues looked familiar, so I thought I'd do a basic comparison:
Reiser4 had the same problems with fsync -- basically, fsync called sync. This was because their sync is actually a damned good idea -- wait till you have to (memory pressure, sync call, whatever), then shove the entire tree that you're about to write as far left as it can go before writing. This meant awesome small-file performance -- as long as you have enough RAM, it's like working off a ramdisk, and when you flush, it packs them just about as tightly as you can with a filesystem. It also meant far less fragmentation -- allocate-on-flush, like XFS, but given a gig or two of RAM, a flush wasn't often.
The downside: Packing files that tightly is going to fragment more in the long run. This is why it's common practice for defragmenters to insert "air holes". Also, the complexity of the sync process is probably why fsync sucked so much. (I wouldn't mind so much if it was smarter -- maybe sync a single file, but add any small files to make sure you fill up a block -- but syncing EVERYTHING was a mistake, or just plain lazy.) Worse, it causes reliability problems -- unless you sync (or fsync), you have no idea if your data will be written now, or two hours from now, or never (given enough RAM).
(ZFS probably isn't as bad, given it's probably much easier to slice your storage up into smaller filesystems, one per task. But it's a valid gotcha -- without knowing that, I'd have just thrown most things into the same huge filesystem.)
There's another problem with reliability: Basically, every fast journalling filesystem nowadays is going to do out-of-order write operations. Entirely too many hacks depend on ordered writes (ext3 default, I think) for reliability, because they use a simple scheme for file updating: Write to a new temporary file, then rename it on top of the old file. The problem is, with out-of-order writes, it could do the rename before writing the data, giving you a corrupt temporary file in place of the "real" one, and no way to go back, even if the rename is atomic. The only way to get around this with traditional UNIX semantics is to stick to ordered writes, or do an fsync before each rename, killing performance.
I think the POSIX filesystem API is too simplistic and low-level to do this properly. On ordered filesystems, tempfile-then-rename does the Right Thing -- either everything gets written to disk properly, or not enough to hurt anything. Renames are generally atomic on journalled filesystems, so either you have the new file there after a crash, or you simply delete the tempfile. And there's no need to sync, especially if you're doing hundreds or thousands of these at once, as part of some larger operation. Often, it's not like this is crucial data that you need to be flushed out to disk RIGHT NOW, you just need to make sure that when it does get flushed, it's in the right order. You can do a sync call after the last of them is done.
Problem is, there are tons of other write operations for which it makes a lot of sense to reorder things. In fact, some disks do that on a hardware level, intentionally -- nvidia calls it "native command queuing". Using "ordered mode" is just another hack, and its drawback is slowing down absolutely every operation just so the critical ones will work. But so many are critical, when you think about it -- doesn't vim use the same trick?
What's needed is a transaction API -- yet another good idea that was planned for someday, maybe, in Reiser4. After all, single filesystem-metadata-level operations are generally guaranteed atomic, so I would guess most filesystems are able to handle complex transactions -- we just need a way for the program to specify it.
The fragmentation issue I see as a simple tradeoff: Packing stuff tightly saves you space and gives you performance, but increases fragmentation. Running a defragger (or "repacker") every once in awhile would have been nice. Problem is, they never got one written. Common UNIX (and Mac) philosoph
There's already an inconsistency there ("Unlimited" local calls really is unlimited, but "Unlimited" Internet access very rarely is). But even ignoring that, law should be close to ethics. That's why it exists in the first place.
If you're going to be that pedantic, I was talking about AJAX, not Ajax.
Or better, either advertise 100k or build the other 180 megs you're charging us for.
If you have 20 megs upstream, you get to sell 20 megs downstream, unfiltered, unshaped, un-messed-with. Then we get to put the whole "net neutrality" debate behind us, among other things.
The government is what protects us from false advertising. Net neutrality, in particular, should be required by anything that wants to claim it is an ISP -- otherwise, it should not be able to call it "Internet access".
Also, remember that plenty of ISPs receive government funding to build the network infrastructure (which they haven't been doing), and often, there's only one or two in an area. So, everything you just suggested is something customers should do, but none of it excuses asshatry from any ISP, for any reason.
That still seems intentionally misleading, given the "Up to" implies different plans you could buy, like 512Kb, 2Mb, 6Mb, and 12Mb. I bet when you get right down to it, your bill is for 12Mb service, not "Up to 12Mb".
Besides, in what other industry is this OK? When I buy phone service with unlimited local calls, it doesn't say "Up to unlimited local calls" or "Unlimited local calls that might sound like crap". And when I don't have local service, I complain to my phone company, simple as that.
And anyway, if that did work for covering asses so well, couldn't I sell dialup service as "Up to 1Gb!" Sure, it'll never get there, never could, but I can just claim I never guaranteed any amount of bandwidth. I can then go on to say that you should have read the fine print on "Unlimited hours" and go disconnect you for the rest of the day, while laughing maniacally and rolling in a pile of money.
Not true. In fact, the only place where I see bandwidth advertised clearly and truthfully is in web hosting, where you simply buy a fixed amount of data transfer, usually on a 10 or 100 mbit pipe. No way you'll saturate the thing with whatever you're paying for monthly, but at least you know exactly what you're paying for.
My ISP, and maybe your ISP, are likely exceptions. I pretty much have 1 Mbit, pretty much all the time. I can usually saturate it for weeks at a time with BitTorrent, and the worst I ever slow down to is half.
But most ISPs aren't as honest. They sell "burst bandwidth", which is their way of weaseling out of any responsibility. They'll claim "UNLIMITED", but what they mean by that is, you can stay connected as long as you want, and transfer as much as you can, without paying extra. They don't mean that you'll be able to saturate the 6 Mbits 24/7, unless no one else is connected.
And there are occasionally traffic jams, which suggests the infrastructure there could be improved. But whatever, I'm not paying a monthly fee specifically for the purpose of driving on roads in New York. You could argue that I'm paying my taxes there (I live in Iowa, but that's not the point), but the tax forms don't come with a glossy flier with big bold letters saying "UNLIMITED driving!"
I'm not sure how it works with cell phone towers, but I honestly cannot think of anything else that is sold by claiming you get UNLIMITED service, and then not delivering. The only thing that comes close is overbooking, which seems deceptive to me anyway.
More likely, us geeks have known about this all along, and any publicity about the situation might help encourage ISPs to go light up that dark fiber, research that wireless, and actually deliver the bandwidth they've been selling us. It's kind of like, most articles about DRM read to Slashdotters as "Well, duh!", but not everyone even knows DRM exists.
Yes, I know what AJAX stands for. However, the majority of it is something called DHTML (Dynamic HTML), which was simply JavaScript + the HTML DOM.
In fact, most of "AJAX" today is simply DHTML tricks that people were using years ago, but somewhere along the way, JavaScript became something to drive popup ads, and people started thinking you needed Flash to make a dynamic-looking website.
Even the 'X' in AJAX is optional -- plenty of people use JSON instead of XML for their AJAX apps. And the 'A' part? Firefox is certainly threaded, and among other things, it will download a new version of itself in the background (on Windows, at least) and prompt you when it's ready to be installed.
So, I would have called it DHTML, but AJAX is catchier, and it's what people know now. (Besides, it's not really HTML, it's XUL...)
I read Schneier's page because I respect the guy, and I figured he'd know what he was talking about. It already seemed trivially vulnerable to a man-in-the-middle attack, but I wanted to see if I was the only one.
Looks like I'm right:
He actually details a few more problems:
But then, I guess it's the best we've got:
It's called Gecko. Most of Firefox is written in either cross-platform C++, or XUL/JavaScript, which makes it probably the only browser to itself be an AJAX application. (And Mozilla did the same thing long before AJAX was even a word.)
Also, there aren't many virtual machines out there. I agree, we don't need this one -- x86 is just a retarded target for this sort of virtualization -- but even if we count Java, Mono, Parrot, Python, Erlang, and XUL, that's still not a lot of RAM by today's standards. You'd lose more by having to use different GUI toolkits in your C++ app -- one uses wxwindows, one uses GTK+, one uses QT, one uses TK, maybe one even uses Motif or straight OpenGL. And that's just the GUI -- there are all kinds of cross-platform C++ libraries, some (I'd argue) with more overhead than a VM.
Given the choice between running a bunch of GUI toolkits running recompiled C++ code, and a bunch of VMs running on the same GUI toolkit, I'd much prefer the latter.
Also, VMs can theoretically perform better than C, so I'm only counting RAM usage required by different VMs as "overhead".
Great. So why are you writing a cross-platform app that relies on specific hardware or OS features?
Also, it seems much simpler and more elegant to take whatever features you need and abstract them away in a cross-platform library (like QT) rather than virtualization/emulation.
Then you use a different framework. There are at least three or four out there.
A lot of people complain about cross-platform frameworks not feeling native, especially on OS X. In fact, that's the main argument against them. But I fail to see how forcing it to simply be a Linux application and then virtualizing it anywhere improves the situation.
Well, if the one that requires the earlier version isn't updated quickly enough, and if there's only one of it, then... well, it's not particularly easy, but it's not particularly hard, either. Simply install multiple copies of the library. If the package manager doesn't support it, then manually install one of them in a place outside of the normal library paths, and use things like LD_PRELOAD to force the troublesome app to use your library.
In fact, commercial games have used this approach on Linux for ages.
Believe it or not, this isn't as difficult as it's made out to be. The biggest barrier would be convincing your mother that she should know, rather than having her simply say "This is too complicated!" at the first hint that she might actually have to learn something.
But seriously, if you give me a half hour or so with your mother, I will be able to get her to understand it, so $500 is a pretty generous offer. And I could use the money now. Want to send me her email address or something?
I don't think it's particularly ingenious, either.
Except Java does it better. I don't even like Java, but I have to admit, it does it better.
Because it's an ugly, ugly hack -- I'd much rather do something useful, like, say, improve one of the real "compile-once, run anywhere" platforms, or improve package management to where such things aren't needed. We're already mostly there anyway -- no matter what the physical architecture, I can generally easily find a GUI package manager for my distro. If I choose the same distro on all platforms, it'll even look similar. And if I'm on something other than Linux, I simply download the binary for my OS. Even if I'm completely clueless, I can simply browse to the program's website, and it can auto-detect my OS and suggest a version to download -- Firefox does this, for example.
Bonus: It now really does run anywhere, not just "any x86 processor". Yes, I realize you can do emulation as well as virtualization, but that's just retarded -- why would I want to lose at least 50% of the speed because your mother is too lazy to download the right version for her platform? With actual binaries, I can get true 64-bit clean versions, on x86_64 or ppc_64, or even ARM binaries... Can you imagine trying to run Linux inside an x86 emulator on a PocketPC? No wonder so many cell phones use Java instead.
Also? Because it's already been done. Depending on the implementation, it's either called "user-mode Linux" (I am not sure if this runs on OSes other than Linux, but I imagine it'd run on OS X) or Qemu.
Ordinarily, I wouldn't bother criticizing them, but I think what they're doing is actually harmful. I would much rather have something written in Java, or cross-platform with QT or wxwindows, than something that's x86 Linux only because someone told them x86 Linux was "compile-once, run anywhere".