Anyhow, what's up with all those double-dots above half the letters in Finnish? They're *everywhere*!
Ä and Ö are just two quite uninteresting and somewhat unaesthetic vowels. Quite similar to the sounds found in middle of "bad" and "girl" pronounced in American.
But they're quite important, as most people's lives start with exclamation "Ää!" and end with "Öö..." =)
In skimming the article, I realized that an obfuscator does exactly what hes describing.
Well, you know, there's an old saying along the lines of "to err is human, but to screw up really good you need a computer"; since programming is the yang to computer hardware's yin, I'd say "to make unmaintainable code you can use code generators, but to really screw up your code you need a human to write it". =)
Well-designed, but obfuscated, code is decipherable (in theory); code written without any coherence whatsoever, either due to lack of coding standards or due to different coders throwing together features without any planning, tend to be the most difficult to understand.
Users simply shouldn't be asking for AJAX-this or non-AJAX-that.... Users should be reporting bugs, not concerning themselves with the guts of a piece of software.
Note that at no point did I say "AJAX sucks, period." I said "This AJAX-based thing isn't as good as the solution we had in 1997", you know, back in dark ages when CmdrTaco unleashed his new evil minions, Preview and Submit (who, to digress a bit, are frequently mistaken for each other).
A significant difference in these statements, in case it's not obvious, is that former condemns an implementation detail and latter identifies one of the possible causes of a larger problem, which is not an implementation detail but an usability issue.
And yes, I know there's nothing worse than someone who thinks he knows what's wrong at one specific detail but really doesn't. But even they have helpful suggestions that may lead to significant improvements. Ultimately, very little of user feedback is utterly worthless.
There are in fact good reasons for using the same software to track bugs and feature requests
I hate it that despite of over a century of advances in sound recording, we haven't yet managed to record the sound of Sarcasm Flying Right Over One's Head.
That's a bug. That's not a feature request. If a developer has misclassified that as a feature request, then complain about the misclassification, do not complain that they don't consider feature requests to be problems, because they shouldn't and that's not the problem you are experiencing.
Ah, I see. Users are no longer allowed to say "I have an idea that might fix all these problems". Or "I think the old system worked much better than this new one". I'm supposed to file a bug report that this Grand New System designed by Fine Programmers doesn't work efficiently, wait six months, and receive a new version which has the exact same problems, manifesting in a different way, or maybe helpfully categorized as "no, those aren't bugs, they're features".
Then the bug is not that it uses AJAX, the bug is that it makes lots of unnecessary and unwanted entries in your log file.
I could fill two reports: "AJAX stuff floods my server log" and "Old-fashioned editor, please". Devs come with two replies, "It's AJAX, of course it does that, duh, can't fix this, buy a better log analyser" and "New feature requests out of blue, where's the bloody rationale?"
Okay, so my problem was that I started rambling about AJAX in this example. (Do developers really read only the first sentence?) Let me rephrase the request: "Please implement an old-fashioned preview-before-post system, as the current dynamic approach has some usability issues (as detailed in bugreport number such-and-such)." (Assuming the Developers don't get whimpery when I remind them of "usability".)
I apologise wholeheartedly, WWWWolf. That is your real name, isn't it? =)
Sorry, I tried to put my entire full name and family lineage to the name box when I created the user account, but that was too long. As was my full legal name. Therefore, I settled for a nickname. (Even nicknames can be troublesome in Slashdot - "Ungrounded Lightning Rod" had his Rod slashed off.) Under these dire circumstances, I was compelled to add a link to my home page on the World Wide Web. You can find my real name fairly easily from there, in case you're somehow interested in that sort of thing.
Developers curse frigging idiots like you. If you have a -problem- with the preview, file a bug report describing -the problem-.
I blame developers. That's what you get when you use bug tracking system to track feature requests. "Damn! Another whiner wants a new feature! I'd better edit Trac and remove the 'enhancement' severity from the bug reports!" =)
And this is what bugs me about developers: According to them, feature requests are not "problems". I have a problem with Typo story editor (it pushes stuff to the server while I type, lagging it down a bit, then renders the text jerkily, and rearranges and shuffles the browser window while doing so).
Or did it occur to you that I might actually not rant in this style in bug reports and actually write politely? as in "I think this Ajax thing is kewl to the max, but my web server logs have tons of requests to the RPC things - would it be possible to include an old-fashioned edit-then-preview system?"
And I curse developers who don't have guts to call the users idiots without Post Anonymously checked. =)
Typo is so far the greatest blogware I've seen. Was a little bit problematic to get running at first on my web host (they didn't have Ruby and Rails installed, had to build them from source), but it has been working like a dream ever since.
It has one really good side, specifically, it doesn't depend on any particular database. I'm using it on sqlite. Few blogwares offer that as an option. (Especially if nobody really reads my blog. =)
Has one annoying side though - relies on AJAX crap for preview when I type articles. Should file a bug report along the lines of "What's wrong with plain old preview-before-post?" one day...
I refuse to believe Battlezone ever existed. I mean, the thing came out in the dark ages of 1998 and that thing had everything. RTSing and FPSing and ninjaing and hovertank racing and Cold War cliches. Nope, such a great concept obviously never existed.
Or maybe it did exist, it was just that it was too far ahead of its time and most people just forgot about it.
Oh, wait, it did exist, I have the game box and manual and CD and all other stuff right here.::blows dust off the box:: Hmm, now if only I had Windows around to try this one out, maybe I could install it on QEMU...::browses through the computer part drawers and can only find a Windows 95 OEM CD:: No wait, I cannot touch this artifact of evil, looks like the verification has to be done later!
I think Make just gets hung on pondering dependencies or something.
Anyway, the makefile for that entry just does something along the lines of "mv smr.c smr; chmod +x smr". It's an empty file. *NIXes have no problem executing empty files (producing nothing on stdout, so yes, it produces its own source), not sure about Windowses. =)
GCC doesn't seem to like this file - or actually, it *compiles* all right (with -c, it produces an object file with no problems), it just doesn't *link* the executable (undefined reference to `main').
Re:Would gaming companies target this platform?
on
Cedega 5.0 Released
·
· Score: 1
Probably porting to OpenGL.
Porting OpenGL code to Direct3D or vice versa isn't really all that difficult - In the game engine, you manipulate your 3D data on a higher level, and just use the 3D API to draw to the screen, anyway. If the program is designed properly, the rendering side is fairly well concentrated to some specific spots.
I think trying to design existing D3D applications to run on Cedega specifically is more of a bug-hunt on Cedega's side. At worst, the developers always assume the Microsoft's DirectX API is perfect, but if it works wrong on Cedega, it's Cedega's fault. The bug-finding process would work this way:
1) Is it a known bug in Cedega?
2) How does Cedega implement the feature, and how does it differ from MS API?
3a) (commonly) Cedega is buggy, sucks to be us. Report the bug to Transgaming, or fix the Cedega bug ourselves (guess which is more likely outcome for commercial game houses).
3b) (rarely) Our app is clearly wrong, let's fix it.
Re:Would gaming companies target this platform?
on
Cedega 5.0 Released
·
· Score: 1
What would be the point of encouraging game developers to test that their games work in Cedega?
"Hey, we're Linux gamers, we absolutely don't care if you don't make a full-blown native port of your game to Linux, but we would like you to test how this beta-quality compatibility layer works with the game anyway."
Assuming the game company in question gives damn about Linux users, what do you think is easier: Designing a game ground up so that it can be easily ported to Linux, or getting the programming team aquaintated with gigantic gobs of Cedega codebase, spending their time finding out whether or not they have bugs in their, Cedega's or Microsoft's libraries? (And because their game supposedly runs perfectly in real Windows, it's more likely that whatever compatibility issues there are, are Cedega's fault anyway.)
Even if I had the money, I wouldn't be be buying a new console for Christmas. Nor too many games.
There's too much stuff on the market in the holiday time! Everyone's cramming their cruft to holiday markets! People are stressed! Prices are terrible! Everyone's chanting "buy, buy, buy!"
So what if people won't get XBox360 for Christmas. It's not like the world is likely ending midnight, December 26th. There's plenty of time to get one later on.
I was actually quite happy in March when I bought my Nintendo DS on release day - nobody was trying to grab them from my hands. I think the greatest time to buy games is just after Christmas anyway =)
Well, most operating systems have stuff in place to read ISO9660 file systems either directly (mount/mnt/cdrom) or via direct device access (dd if=/dev/cdrom of=cdrom.iso). Audio CDs are different: you can't access the raw data *really* accurately due to lack of correction information present on the disk. (This is a non-issue in CD players, but relevant if you do a digital copy.) Which is why you need monstrous amounts of error-correcting logic in software, like in cdparanoia, and why a CD ripped on two different drives - or even on one drive in different ripper software version, or even just at different time - may not be bitwise identical.
Also, ISO files have only the data of one track of the disk with its filesystem contents; it doesn't have the physical disk layout stored anywhere. If you rip a CD in its raw form, you end up with multiple files,.iso for the data tracks and.cdr for audio tracks and whatnot. Or, you can put the raw data in one file and description of the layout in another (think of bin/cue), but it's no longer an ISO image you can mount on loopback, and if you burn it you need to make sure the burner understands the format!
Errrrrmmmm... I was under impression iD games used still OpenGL rather than Direct3D.
The Windows versions probably do use DirectX, but remember that DirectX is a lot more than just Direct3D - DX is probably used for keyboard and mouse support.
I don't have Q4 yet, but my package of Doom 3 has absolutely no mention of OpenGL even when it definitely uses OpenGL extensively - and the iD software's Linux page definitely says that Q4 needs working OpenGL!
...while we wait for Linux version, is anyone working on getting this stuff to Celestia? Would rock if the two programs could easily use the same data though.
The screenshots seem nice, but regrettably not really too much more impressive than what you can already do with Celestia. =(
This is kind of off-topic but also very much on topic, because it does involve firefox update.
Does anyone know how to make SVG files, you know, scalable?
If I put images to web pages with <img> tag, and specify width and height, the image gets scaled.
But if I do what is recommended for SVG - that is, I create a PNG rendering of the image for backwards compatibility, then use <object data="foo.svg"...><image src="foo.png".../></object>, with width and height specified on both img and object tags, I get a properly scaled PNG image in Firefox 1.0 (which can't interpret the object type in question, so it falls back to the <img> tag, it as it should), and an improperly scaled SVG image in Firefox 1.5 and all other SVG browsers. Some SVG-enabled browsers (MSIE with AdobeSVG, FF1.0 with Inkscape plugin) show original-size SVG images, FF1.5 seems to be really nice and shows scrollbars on the image.
I tried making a small SVG file which uses <foreignObject> to scale the picture, but it didn't seem to work at all with SVG images in FF1.5, plus, it was an awful hack!
So what's supposed to be the web-standards-compliant trick of placing and arbitrary-sized SVG image on a web site, then having the browser scale the frigging scalable vector graphic file to the specified width and height?
I've looked around everywhere, nobody seems to know - anybody here know?
Erm... rootkits (the definition of which I usually think includes "set of tools/OS patches that hide specific files/processes from the sight of users") have just about nothing to do with "root" account as such. I don't know why the heck they're even called that - maybe it was "the k1t that you install after you get r00t".
If you want to call them "kernel modules and userland tool replacements for hiding files and processes", that's just fine with me, but also call them that on Unix as well then, too =)
I think the article provided enough evidence as is. Yes, it is "DRM shovelware", which is an offense in itself. Yes, it's hard to uninstall, which is bad. But it's also trying to hide itself, which is really nasty, and it hides stuff indiscriminately, which is worse.
It is a rootkit, because it messes with the OS to hide specific files. It is a dangerous rootkit, because it hides all files that start with some prefix, not just the specific files used by the DRM mechanism - this could be potentially used to hide more mischief from the same source.
Yes, some people DO install the stuff that comes with their CD's, because sometimes that "crap" gives them the ability to rip so many licensed copies of the song to share with friends.
After being presented with a sell-your-babies-to-the-almighty-record-label EULA, and before shoving awfully encoded WMA format files down their throats.
Hint #1: There's no "copy protection" on CDs. For most parts, it's misshapen multi-session CDs. cdrdao read-cd --session 1... Hint #2: If you're encoding the files to MP3, Vorbis or, good heavens, WMA, digital rips are wayyyy overrated and plain old CD player, analog RCA-to-RCA cable and an audio recorder app can do really wonders. =)
So much for ever getting a real Mac OS X version OpenOffice.org. Spare me your comments about NeoOffice and the X11 version working on OS X.
Okay, but I won't spare you from a small note that Google isn't the only one who contributes to OO.o. They may not exactly have a stellar record on supporting Mac on their own projects, but here, they're contributing stuff on a cross-platform package backed by folks who want to keep it running on Windows, Linux and (to a very small extent) OS X.
I don't think that sudden appearance of Google programmers makes OO.o Linux and OS X support magically disappear over night! That would be very silly!
Absolutely no idea, probably some BSD guy in mid-1990s. Who am I to advertise some ages-old software? And I'm not exactly known to be widely quoted anyway, better not start with such an awful quote. =)
Some on-topic stuff though: I sure hope the supposed Vista symlinks work the way Unix symlinks work; NT world already seems to have several incompatible and not-quite-good-and-working ways of achieving this and one more would just cause confusion. NT definitely needs to borrow more Unixisms, particularly on filesystem side. (NT filesystem isn't done until rm -rf / in Cygwin really deletes everything =)
Re:Allow me to be the first to say...
on
Vista To Get Symlinks?
·
· Score: 5, Informative
(Who was it who said: 'Those who don't know UNIX are condemned to recreate it. Badly.' ?)
$ fortune -m 'condemned' ...
Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer
And those who don't understand fortune(1) are condemned to ask about quotes =)
Several problems with just plain text, though. As noted, character sets are pretty painful (I hear the Japanese call this problem "ghost characters", which is a pretty poetic name for what we in Finland call "it's %$#@ng year 2005 and we still can't get those $%@#ng Nordic letters right every time"). And, there's also the issue of linebreaks (Is it Windowsesque CR+LF or Unixesque LF? I hope Mac finally moved to the LF camp in OS X.)
Another issue, and much bigger in my opinion, is styling/markup. You can't mark up structure. "Just send me your articles as plain text." "Okay, what do I do with the subheadings?" "Errrmmm... put '@subheading:' at the beginning of the line?" You absolutely can't hide any formatting details to the file, aside of whitespace which may get ignored, and if you start adding control sequences, you're no longer doing plain text - you've made up your own markup language, and you may as well start doing HTML or DocBook. Or maybe you want to make OpenDocumentText by hand.
Also, if you have plain text files you tend to slide towards "the more Latin-1 it is, the better" kind of feel, so instead of en dashes you have minus signs and instead of double quotes you get inch marks. Okay, few people bother to correct this on word processors either unless the thing does it for them...
The horrible truth is that graphing, in general, tends to suck in all office packages. Back in the DOS era, I was a schoolkid and the only thing we had that could make graphs was Works, and it was really pain after a while (and this was just school project stuff, nothing as glorious as 10000 item plots); then, for me, came a long lull of not needing to do any graphing, and recently, now that I've had to fight Excel and OO.o, they've made the whole thing "easier" and almost impossible to use effectively for anything
Nowadays I keep going back to GNUPLOT if I want to graph something. Pain to work with (no "click and it does it"), but at least it gives understandable output without too much messing. Export stuff to CSV from OpenOffice.org Calc, let GNUPLOT shred it for a while, and it spits out EPS. Works perfectly each time, plus the graphs it makes have "dull scientific" look rather than "idiotic business" look, and I prefer dull scientific look any day =)
Is that enough to equip a full sized office with aeron chairs and furniture?
Come on, this is a Google project! Just give a small hint to Microsoft and that chair problem will solve itself. Just remember to be on guard and you'll be able to catch the thrown chairs without injuring yourself! =)
But seriously, I think the folks who get the money will need to budget the thing wisely and won't blow it on furniture first, even when ergonomy is very important...
I had so much fun reading the live-blogging features last time (even though I caught them the next day.) Based on these nominations, the event will be just as much of a trainwreck it was in the last two times.
Hopefully there'll be more unpaid external expert commenting this time. Now here's one award show that just begs to be torn to shreds =)
Slashdot Mirror
Ä and Ö are just two quite uninteresting and somewhat unaesthetic vowels. Quite similar to the sounds found in middle of "bad" and "girl" pronounced in American.
But they're quite important, as most people's lives start with exclamation "Ää!" and end with "Öö..." =)
Well, you know, there's an old saying along the lines of "to err is human, but to screw up really good you need a computer"; since programming is the yang to computer hardware's yin, I'd say "to make unmaintainable code you can use code generators, but to really screw up your code you need a human to write it". =)
Well-designed, but obfuscated, code is decipherable (in theory); code written without any coherence whatsoever, either due to lack of coding standards or due to different coders throwing together features without any planning, tend to be the most difficult to understand.
Note that at no point did I say "AJAX sucks, period." I said "This AJAX-based thing isn't as good as the solution we had in 1997", you know, back in dark ages when CmdrTaco unleashed his new evil minions, Preview and Submit (who, to digress a bit, are frequently mistaken for each other).
A significant difference in these statements, in case it's not obvious, is that former condemns an implementation detail and latter identifies one of the possible causes of a larger problem, which is not an implementation detail but an usability issue.
And yes, I know there's nothing worse than someone who thinks he knows what's wrong at one specific detail but really doesn't. But even they have helpful suggestions that may lead to significant improvements. Ultimately, very little of user feedback is utterly worthless.
I hate it that despite of over a century of advances in sound recording, we haven't yet managed to record the sound of Sarcasm Flying Right Over One's Head.
Ah, I see. Users are no longer allowed to say "I have an idea that might fix all these problems". Or "I think the old system worked much better than this new one". I'm supposed to file a bug report that this Grand New System designed by Fine Programmers doesn't work efficiently, wait six months, and receive a new version which has the exact same problems, manifesting in a different way, or maybe helpfully categorized as "no, those aren't bugs, they're features".
I could fill two reports: "AJAX stuff floods my server log" and "Old-fashioned editor, please". Devs come with two replies, "It's AJAX, of course it does that, duh, can't fix this, buy a better log analyser" and "New feature requests out of blue, where's the bloody rationale?"
Okay, so my problem was that I started rambling about AJAX in this example. (Do developers really read only the first sentence?) Let me rephrase the request: "Please implement an old-fashioned preview-before-post system, as the current dynamic approach has some usability issues (as detailed in bugreport number such-and-such)." (Assuming the Developers don't get whimpery when I remind them of "usability".)
Sorry, I tried to put my entire full name and family lineage to the name box when I created the user account, but that was too long. As was my full legal name. Therefore, I settled for a nickname. (Even nicknames can be troublesome in Slashdot - "Ungrounded Lightning Rod" had his Rod slashed off.) Under these dire circumstances, I was compelled to add a link to my home page on the World Wide Web. You can find my real name fairly easily from there, in case you're somehow interested in that sort of thing.
I blame developers. That's what you get when you use bug tracking system to track feature requests. "Damn! Another whiner wants a new feature! I'd better edit Trac and remove the 'enhancement' severity from the bug reports!" =)
And this is what bugs me about developers: According to them, feature requests are not "problems". I have a problem with Typo story editor (it pushes stuff to the server while I type, lagging it down a bit, then renders the text jerkily, and rearranges and shuffles the browser window while doing so).
Or did it occur to you that I might actually not rant in this style in bug reports and actually write politely? as in "I think this Ajax thing is kewl to the max, but my web server logs have tons of requests to the RPC things - would it be possible to include an old-fashioned edit-then-preview system?"
And I curse developers who don't have guts to call the users idiots without Post Anonymously checked. =)
Typo is so far the greatest blogware I've seen. Was a little bit problematic to get running at first on my web host (they didn't have Ruby and Rails installed, had to build them from source), but it has been working like a dream ever since.
It has one really good side, specifically, it doesn't depend on any particular database. I'm using it on sqlite. Few blogwares offer that as an option. (Especially if nobody really reads my blog. =)
Has one annoying side though - relies on AJAX crap for preview when I type articles. Should file a bug report along the lines of "What's wrong with plain old preview-before-post?" one day...
I refuse to believe Battlezone ever existed. I mean, the thing came out in the dark ages of 1998 and that thing had everything. RTSing and FPSing and ninjaing and hovertank racing and Cold War cliches. Nope, such a great concept obviously never existed.
Or maybe it did exist, it was just that it was too far ahead of its time and most people just forgot about it.
Oh, wait, it did exist, I have the game box and manual and CD and all other stuff right here. ::blows dust off the box:: Hmm, now if only I had Windows around to try this one out, maybe I could install it on QEMU... ::browses through the computer part drawers and can only find a Windows 95 OEM CD:: No wait, I cannot touch this artifact of evil, looks like the verification has to be done later!
I think Make just gets hung on pondering dependencies or something.
Anyway, the makefile for that entry just does something along the lines of "mv smr.c smr; chmod +x smr". It's an empty file. *NIXes have no problem executing empty files (producing nothing on stdout, so yes, it produces its own source), not sure about Windowses. =)
GCC doesn't seem to like this file - or actually, it *compiles* all right (with -c, it produces an object file with no problems), it just doesn't *link* the executable (undefined reference to `main').
Probably porting to OpenGL.
Porting OpenGL code to Direct3D or vice versa isn't really all that difficult - In the game engine, you manipulate your 3D data on a higher level, and just use the 3D API to draw to the screen, anyway. If the program is designed properly, the rendering side is fairly well concentrated to some specific spots.
I think trying to design existing D3D applications to run on Cedega specifically is more of a bug-hunt on Cedega's side. At worst, the developers always assume the Microsoft's DirectX API is perfect, but if it works wrong on Cedega, it's Cedega's fault. The bug-finding process would work this way:
1) Is it a known bug in Cedega?
2) How does Cedega implement the feature, and how does it differ from MS API?
3a) (commonly) Cedega is buggy, sucks to be us. Report the bug to Transgaming, or fix the Cedega bug ourselves (guess which is more likely outcome for commercial game houses).
3b) (rarely) Our app is clearly wrong, let's fix it.
What would be the point of encouraging game developers to test that their games work in Cedega?
"Hey, we're Linux gamers, we absolutely don't care if you don't make a full-blown native port of your game to Linux, but we would like you to test how this beta-quality compatibility layer works with the game anyway."
Assuming the game company in question gives damn about Linux users, what do you think is easier: Designing a game ground up so that it can be easily ported to Linux, or getting the programming team aquaintated with gigantic gobs of Cedega codebase, spending their time finding out whether or not they have bugs in their, Cedega's or Microsoft's libraries? (And because their game supposedly runs perfectly in real Windows, it's more likely that whatever compatibility issues there are, are Cedega's fault anyway.)
No games for holidays.
Even if I had the money, I wouldn't be be buying a new console for Christmas. Nor too many games.
There's too much stuff on the market in the holiday time! Everyone's cramming their cruft to holiday markets! People are stressed! Prices are terrible! Everyone's chanting "buy, buy, buy!"
So what if people won't get XBox360 for Christmas. It's not like the world is likely ending midnight, December 26th. There's plenty of time to get one later on.
I was actually quite happy in March when I bought my Nintendo DS on release day - nobody was trying to grab them from my hands. I think the greatest time to buy games is just after Christmas anyway =)
Well, most operating systems have stuff in place to read ISO9660 file systems either directly (mount /mnt/cdrom) or via direct device access (dd if=/dev/cdrom of=cdrom.iso). Audio CDs are different: you can't access the raw data *really* accurately due to lack of correction information present on the disk. (This is a non-issue in CD players, but relevant if you do a digital copy.) Which is why you need monstrous amounts of error-correcting logic in software, like in cdparanoia, and why a CD ripped on two different drives - or even on one drive in different ripper software version, or even just at different time - may not be bitwise identical.
Also, ISO files have only the data of one track of the disk with its filesystem contents; it doesn't have the physical disk layout stored anywhere. If you rip a CD in its raw form, you end up with multiple files, .iso for the data tracks and .cdr for audio tracks and whatnot. Or, you can put the raw data in one file and description of the layout in another (think of bin/cue), but it's no longer an ISO image you can mount on loopback, and if you burn it you need to make sure the burner understands the format!
Errrrrmmmm... I was under impression iD games used still OpenGL rather than Direct3D.
The Windows versions probably do use DirectX, but remember that DirectX is a lot more than just Direct3D - DX is probably used for keyboard and mouse support.
I don't have Q4 yet, but my package of Doom 3 has absolutely no mention of OpenGL even when it definitely uses OpenGL extensively - and the iD software's Linux page definitely says that Q4 needs working OpenGL!
...while we wait for Linux version, is anyone working on getting this stuff to Celestia? Would rock if the two programs could easily use the same data though.
The screenshots seem nice, but regrettably not really too much more impressive than what you can already do with Celestia. =(
If you want OS X application bundles, you can have them today if you want.
Stick your app in an appropriate Applications directory and type "openapp Whatever.app".
And if you merely want appbundle-*like* systems, I think there's plenty of them floating around.
This is kind of off-topic but also very much on topic, because it does involve firefox update.
Does anyone know how to make SVG files, you know, scalable?
If I put images to web pages with <img> tag, and specify width and height, the image gets scaled.
But if I do what is recommended for SVG - that is, I create a PNG rendering of the image for backwards compatibility, then use <object data="foo.svg" ...><image src="foo.png" .../></object>, with width and height specified on both img and object tags, I get a properly scaled PNG image in Firefox 1.0 (which can't interpret the object type in question, so it falls back to the <img> tag, it as it should), and an improperly scaled SVG image in Firefox 1.5 and all other SVG browsers. Some SVG-enabled browsers (MSIE with AdobeSVG, FF1.0 with Inkscape plugin) show original-size SVG images, FF1.5 seems to be really nice and shows scrollbars on the image.
I tried making a small SVG file which uses <foreignObject> to scale the picture, but it didn't seem to work at all with SVG images in FF1.5, plus, it was an awful hack!
So what's supposed to be the web-standards-compliant trick of placing and arbitrary-sized SVG image on a web site, then having the browser scale the frigging scalable vector graphic file to the specified width and height?
I've looked around everywhere, nobody seems to know - anybody here know?
Erm... rootkits (the definition of which I usually think includes "set of tools/OS patches that hide specific files/processes from the sight of users") have just about nothing to do with "root" account as such. I don't know why the heck they're even called that - maybe it was "the k1t that you install after you get r00t".
If you want to call them "kernel modules and userland tool replacements for hiding files and processes", that's just fine with me, but also call them that on Unix as well then, too =)
I think the article provided enough evidence as is. Yes, it is "DRM shovelware", which is an offense in itself. Yes, it's hard to uninstall, which is bad. But it's also trying to hide itself, which is really nasty, and it hides stuff indiscriminately, which is worse.
It is a rootkit, because it messes with the OS to hide specific files. It is a dangerous rootkit, because it hides all files that start with some prefix, not just the specific files used by the DRM mechanism - this could be potentially used to hide more mischief from the same source.
After being presented with a sell-your-babies-to-the-almighty-record-label EULA, and before shoving awfully encoded WMA format files down their throats.
Hint #1: There's no "copy protection" on CDs. For most parts, it's misshapen multi-session CDs. cdrdao read-cd --session 1 ... Hint #2: If you're encoding the files to MP3, Vorbis or, good heavens, WMA, digital rips are wayyyy overrated and plain old CD player, analog RCA-to-RCA cable and an audio recorder app can do really wonders. =)
Okay, but I won't spare you from a small note that Google isn't the only one who contributes to OO.o. They may not exactly have a stellar record on supporting Mac on their own projects, but here, they're contributing stuff on a cross-platform package backed by folks who want to keep it running on Windows, Linux and (to a very small extent) OS X.
I don't think that sudden appearance of Google programmers makes OO.o Linux and OS X support magically disappear over night! That would be very silly!
Absolutely no idea, probably some BSD guy in mid-1990s. Who am I to advertise some ages-old software? And I'm not exactly known to be widely quoted anyway, better not start with such an awful quote. =)
Some on-topic stuff though: I sure hope the supposed Vista symlinks work the way Unix symlinks work; NT world already seems to have several incompatible and not-quite-good-and-working ways of achieving this and one more would just cause confusion. NT definitely needs to borrow more Unixisms, particularly on filesystem side. (NT filesystem isn't done until rm -rf / in Cygwin really deletes everything =)
$ fortune -m 'condemned'
...
Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer
And those who don't understand fortune(1) are condemned to ask about quotes =)
Several problems with just plain text, though. As noted, character sets are pretty painful (I hear the Japanese call this problem "ghost characters", which is a pretty poetic name for what we in Finland call "it's %$#@ng year 2005 and we still can't get those $%@#ng Nordic letters right every time"). And, there's also the issue of linebreaks (Is it Windowsesque CR+LF or Unixesque LF? I hope Mac finally moved to the LF camp in OS X.)
Another issue, and much bigger in my opinion, is styling/markup. You can't mark up structure. "Just send me your articles as plain text." "Okay, what do I do with the subheadings?" "Errrmmm... put '@subheading:' at the beginning of the line?" You absolutely can't hide any formatting details to the file, aside of whitespace which may get ignored, and if you start adding control sequences, you're no longer doing plain text - you've made up your own markup language, and you may as well start doing HTML or DocBook. Or maybe you want to make OpenDocumentText by hand.
Also, if you have plain text files you tend to slide towards "the more Latin-1 it is, the better" kind of feel, so instead of en dashes you have minus signs and instead of double quotes you get inch marks. Okay, few people bother to correct this on word processors either unless the thing does it for them...
The horrible truth is that graphing, in general, tends to suck in all office packages. Back in the DOS era, I was a schoolkid and the only thing we had that could make graphs was Works, and it was really pain after a while (and this was just school project stuff, nothing as glorious as 10000 item plots); then, for me, came a long lull of not needing to do any graphing, and recently, now that I've had to fight Excel and OO.o, they've made the whole thing "easier" and almost impossible to use effectively for anything
Nowadays I keep going back to GNUPLOT if I want to graph something. Pain to work with (no "click and it does it"), but at least it gives understandable output without too much messing. Export stuff to CSV from OpenOffice.org Calc, let GNUPLOT shred it for a while, and it spits out EPS. Works perfectly each time, plus the graphs it makes have "dull scientific" look rather than "idiotic business" look, and I prefer dull scientific look any day =)
Come on, this is a Google project! Just give a small hint to Microsoft and that chair problem will solve itself. Just remember to be on guard and you'll be able to catch the thrown chairs without injuring yourself! =)
But seriously, I think the folks who get the money will need to budget the thing wisely and won't blow it on furniture first, even when ergonomy is very important...
I had so much fun reading the live-blogging features last time (even though I caught them the next day.) Based on these nominations, the event will be just as much of a trainwreck it was in the last two times.
Hopefully there'll be more unpaid external expert commenting this time. Now here's one award show that just begs to be torn to shreds =)