Now that the profile of this has been raised, I'd bet even odds that an exploitable bug in some GNOME desktop component is posted to BUGTRAQ within a week.
This is just asking for trouble. And, given past history, so unbelievably stupid.
Without antialiasing X is a non starter for a whole range of publishing apps
No, it means the applications need to render fonts themselves. This sucks, but it's not a show-stopper.
and in all the other apps, MOST PEOPLE THINK IT LOOKS LIKE SHIT
xterm is another app. I haven't heard anybody complain about the fonts in xterm.
Resorting to the cop-out that "well at low resolutions, antialiasing just doesn't work as intended" is a weaseling , pussy-ass, excuse for a fatally obsolescent system.
Yes it is. I didn't intend it as an excuse.
I don't give a fuck about your low res display, nor does the rest of the word.
100 dpi is not high resolution. Or do you really have a 300 dpi monitor?
anti-aliased text is actually much more readable in general than standard text.
Here's an experiment to do: Go to a Windows machine, run any program with a standard single line text input widget, type some gibberish, and take a good look at the font. Not anti-aliased, right? (Perhaps in some configurations, it may be, but I believe not by default.) Hmm.
At low resolutions, and allowing a choice of text size and alignment that suits the resolution, it is non-anti-aliased text that looks far clearer. Anti-aliased text at low resolutions looks dim and fuzzy. However, as you point out, it is a huge win for WYSIWYG text, when arbitrary positioning, size, and perhaps rotation must be supported.
I've been involved in efforts to implement both an XML interpreter and a Macromedia Flash interpreter. I know which one was easier, and it wasn't the Flash interpreter.
How many guesses do I get?;)
Anyway, your statement borders on meaningless. Do you mean parser when you say interpreter? If so, do you just mean getting the document into a data structure? If so, it's an unfair comparison, because the data structure from parsing a Flash document is likely immediately useful for manipulating Flash content, whereas the data structure from parsing an XML document requires more interpretation before it's useful.
In my experience, custom binary formats are usually easier to parse, because you know exactly what to expect (assuming they're documented, of course), and they end up being mostly follow-your-nose exercises. Whereas XML is (obviously) much more flexible, resulting in more possibilities for the parser to handle. On the other hand, binary formats (being typically less eXtensible) can get ugly more easily, so I can imagine that Flash might be a pain.
Because this is an XML-based format, it should be easy to implement
You misspelled "a royal pain in the *ss". As the author of Gill makes painfully clear, vector graphics is hard, standards compliance makes it harder, and XML (with all the baggage it entails) makes it a monster. Care to share why you thought XML would make it easy?
And wouldn't it be neat to have a freely
available, widely used free-both-ways vector animation format?
And wouldn't it be neat if everyone was happy, shared their music, and ran Linux on Alpha? Maybe, but it'll be a long road before we get there.
This guy starts by saying that the original reason for patents/copyright was okay, but that governments having the power to grant this is totally corrupting so - let's throw it all out, there is no real justification for it. That is so much nonsense.
Regardless of whether you are right, he makes an important point that you appear to miss. That is that the government has the responsibility to justify IP in terms of benefit to the citizenry. If the defenders of IP can't make that case, it should be thrown out; there is no a priori right to IP.
I'm happy with the humble diff3. The reason is simple: it finds the conflicts, then gets out of the way and lets me use my editor for the real work. The familiarity of the navigation and editing commands, along with amenities like syntax highlighting, typically outweigh the advantages of a dedicated merge tool. Most non-trivial merges require understanding the changes in the context of the whole file, for which an editor is well suited.
The other tool I have significant experience with is the Rational ClearCase merge tool. This is fast for the simplest of conflicts, when the conflicting sections are short and you're already familiar with the deltas on the two branches. Anything harder, and it gets awkward.
Now, Rational's GUI's absolutely suck, so maybe something with a better interface could win me over, but it would have to be pretty slick to compare with vim.
Splendid! You expressed my disappointment with RPG's, and various campaign-style semi-RPG's, better than I ever could.
Here's my critique. I find that these games offer enough semblance of realism and complexity to convince you that your intellect is shaping the outcome in rich and subtle ways; when in fact the range of possible outcomes is limited and has a coarse-grained dependence on your inputs. Generally, while your skill affects how slowly or quickly you advance, steady progression towards victory is inevitible once you've mastered the basic moves. Eventually (usually as the sun rises on a new day) you realize that you're no longer investing any creativity, yet you're still acquiring ability after ability, hoarding gold piece after gold piece, and all you can do is feel like a dupe.
Other human players help to some degree, but to me they can't overcome fundamental inflexibilities in the games.
I haven't played all that many games, but I'm thinking of Dune, Freeciv, Ultima. All great fun at first, but ultimately vapid.
As pleasant as it is to suppose good that security practices are followed, I guarentee there are scads of home Linux boxes with rpc.statd running and no firewall.
Both bugs are serious, but the Linux exploit only affects servers.
No--this is a critical misunderstanding! rpc.statd is run by NFS client machies. And probably (this is a guess) running by default on machines with NFS client support installed.
Heck, I'll analyze my post. I had read about both the nfs exploit and the outlook exploit on Bugtraq (and maybe elsewhere) before the Slashdot article. I thought both were stunningly serious, and that it was incredibly ironic, even perversely pleasing, that major holes in linux and microsoft were found one upon the other.
Then I read Taco's post. He pointed out one irony, to be sure, but I was bowled over by the meta-irony that he overlooked the overwhelmingly greater irony--that Slashdot had failed to cover a similarly embarassing linux exploit.
So, I couldn't resist the urge to parody his article. I tend to agree that the Micrsoft bug is the more damaging, but both are of sufficient magnitude that both parties should take a good hard look in the mirror.
PS. I don't think I've ever had a post moderated four ways:-)
Posted never by no-one from the not-all-that-surprising dept. Yes, remote root on recent versions of (probably) all Linux-based systems that include NFS. Fortunately, most of them seem to have issued updates already. See the Security Focus Record for a summary (and, yes, an exploit). The irony is of course that we pretend to be concerned with security, but we really care only for ridiculing Microsoft, so when something this serious hits Linux, we don't even report it.
ESR covers this in his standard spiel. He makes some compelling points:
Your super-secret proprietary technology probably isn't as special as you think it is. Companies tend to exaggerate the value of their information. As the Cluetrain clue says, "Most of the secrets you keep no one would bother reading even if you delivered them with the morning newspaper.".
If your competitors care about your super-secret proprietary technology, they're already reverse engineering your Windows drivers. Reverse engineering is surprisingly effective--how much of an additional benefit would source code give them?
If your competitors are busy duplicating your last-generation technology, they're exactly where you want them--in the rear-view mirror! If they're following your tracks, you can turn it into major tactical and strategic (not to mention PR) advantages. This depends strongly on the particulars of your industry and product, however.
ESR covers this in his standard spiel. He makes some compelling points:
Your super-secret proprietary technology probably isn't as special as you think it is. Companies tend to exaggerate the value of their information. As the Cluetrain clue says, "Most of the secrets you keep no one would bother reading even if you delivered them with the morning newspaper.".
If your competitors care about your super-secret proprietary technology, they're already reverse engineering your Windows drivers. Reverse engineering is surprisingly effective--how much of an additional benefit would source code give them?
If your competitors are busy duplicating your last-generation technology, they're exactly where you want them--in the rear-view mirror! If they're following your tracks, you can turn it into major tactical and strategic (not to mention PR) advantages. This depends strongly on the particulars of your industry and product, however.
There is no planetary-protection-related objection to the disposal of Galileo by intentional or unintentional impact with Io or Jupiter.
We have a pretty good idea of what life might be on Galileo and the conditions under which it can survive, and we have a pretty good idea of what Jupiter and Io are like. If researchers don't think our microbes have a chance in those environments, I see no reason to doubt it.
If you're clever enough to come up with some other place for this ship to go, great, but otherwise cut the Sci Fi fantasizing.
You seem to have two misconceptions. First, not any group of people is a committee. A research group at a university or lab is more likely to come up with a clean solution than a team at Microsoft. Second, standardized by committee is not the same as designed by committee. The best standards codify existing (designed and implemented) practices. Even when a committee takes over maintenance of an API, they have the original design to guide them.
As for your particular examples: libc is basically what the original Unix guys wrote. C++ was designed by Stroustrup. STL was shepherded by Stepanov. SQL is shit, but we're stuck with it on all platforms. I don't know OpenGL, but good teams at start-ups often produce elegant designs. I don't know the X API, but X was designed by a research group at MIT, and for all its shortcomings has withstood time quite well.
And Perl (why do people think it's all caps?) makes my programming life worth living.
Unix is hugely legacy--but I argue that for the most part it's a good legacy! Old != bad. How much have the core Unix API had to change over the years? How much back-compatilibity does a typical Linux system support? Much less than in "API of the week" Win32 land.
MFC has source, but many other libraries do not. I didn't find kernel source or IIS source on the MSDN CD's.
And yes, Microsoft is renouned for their internal testing, but you must agree that there is a pronounced Microsoft mentality when it comes to development tools. Microsoft is a pretty self-contained culture, so I think their developers may have a hard time thinking outside that mentality. It's not a matter of the tools working "well", which I didn't dispute, it's a matter of style.
Quoth Jobs, "The think about Microsoft is, they have no taste". This rings true to me--but about the tools and API's, not the UI.
The libraries you use are open. You can read (and marvel at or laugh at) their source code, debug them, fix them, and participate in their development communities.
The API's you program against were mostly written by creative people with taste and community feedback; not by committees with deadlines, backwards compatibility requirements, an internal review only, and a narrow Microsoft mindset.
Really, development on a free platform is just more fun!
Slashdot Mirror
I like his Microsoft screwing policy, but I don't like his Debian screwing policy.
This is just asking for trouble. And, given past history, so unbelievably stupid.
No, it means the applications need to render fonts themselves. This sucks, but it's not a show-stopper.
and in all the other apps, MOST PEOPLE THINK IT LOOKS LIKE SHIT
xterm is another app. I haven't heard anybody complain about the fonts in xterm.
Resorting to the cop-out that "well at low resolutions, antialiasing just doesn't work as intended" is a weaseling , pussy-ass, excuse for a fatally obsolescent system.
Yes it is. I didn't intend it as an excuse.
I don't give a fuck about your low res display, nor does the rest of the word.
100 dpi is not high resolution. Or do you really have a 300 dpi monitor?
Here's an experiment to do: Go to a Windows machine, run any program with a standard single line text input widget, type some gibberish, and take a good look at the font. Not anti-aliased, right? (Perhaps in some configurations, it may be, but I believe not by default.) Hmm.
At low resolutions, and allowing a choice of text size and alignment that suits the resolution, it is non-anti-aliased text that looks far clearer. Anti-aliased text at low resolutions looks dim and fuzzy. However, as you point out, it is a huge win for WYSIWYG text, when arbitrary positioning, size, and perhaps rotation must be supported.
How many guesses do I get? ;)
Anyway, your statement borders on meaningless. Do you mean parser when you say interpreter? If so, do you just mean getting the document into a data structure? If so, it's an unfair comparison, because the data structure from parsing a Flash document is likely immediately useful for manipulating Flash content, whereas the data structure from parsing an XML document requires more interpretation before it's useful.
In my experience, custom binary formats are usually easier to parse, because you know exactly what to expect (assuming they're documented, of course), and they end up being mostly follow-your-nose exercises. Whereas XML is (obviously) much more flexible, resulting in more possibilities for the parser to handle. On the other hand, binary formats (being typically less eXtensible) can get ugly more easily, so I can imagine that Flash might be a pain.
You misspelled "a royal pain in the *ss". As the author of Gill makes painfully clear, vector graphics is hard, standards compliance makes it harder, and XML (with all the baggage it entails) makes it a monster. Care to share why you thought XML would make it easy?
And wouldn't it be neat to have a freely available, widely used free-both-ways vector animation format?
And wouldn't it be neat if everyone was happy, shared their music, and ran Linux on Alpha? Maybe, but it'll be a long road before we get there.
I'm happy with the humble diff3. The reason is simple: it finds the conflicts, then gets out of the way and lets me use my editor for the real work. The familiarity of the navigation and editing commands, along with amenities like syntax highlighting, typically outweigh the advantages of a dedicated merge tool. Most non-trivial merges require understanding the changes in the context of the whole file, for which an editor is well suited.
The other tool I have significant experience with is the Rational ClearCase merge tool. This is fast for the simplest of conflicts, when the conflicting sections are short and you're already familiar with the deltas on the two branches. Anything harder, and it gets awkward.
Now, Rational's GUI's absolutely suck, so maybe something with a better interface could win me over, but it would have to be pretty slick to compare with vim.
Splendid! You expressed my disappointment with RPG's, and various campaign-style semi-RPG's, better than I ever could.
Here's my critique. I find that these games offer enough semblance of realism and complexity to convince you that your intellect is shaping the outcome in rich and subtle ways; when in fact the range of possible outcomes is limited and has a coarse-grained dependence on your inputs. Generally, while your skill affects how slowly or quickly you advance, steady progression towards victory is inevitible once you've mastered the basic moves. Eventually (usually as the sun rises on a new day) you realize that you're no longer investing any creativity, yet you're still acquiring ability after ability, hoarding gold piece after gold piece, and all you can do is feel like a dupe.
Other human players help to some degree, but to me they can't overcome fundamental inflexibilities in the games.
I haven't played all that many games, but I'm thinking of Dune, Freeciv, Ultima. All great fun at first, but ultimately vapid.
And mail is nearly always filtered at the MTA.
As pleasant as it is to suppose good that security practices are followed, I guarentee there are scads of home Linux boxes with rpc.statd running and no firewall.
No--this is a critical misunderstanding! rpc.statd is run by NFS client machies. And probably (this is a guess) running by default on machines with NFS client support installed.
Then I read Taco's post. He pointed out one irony, to be sure, but I was bowled over by the meta-irony that he overlooked the overwhelmingly greater irony--that Slashdot had failed to cover a similarly embarassing linux exploit.
So, I couldn't resist the urge to parody his article. I tend to agree that the Micrsoft bug is the more damaging, but both are of sufficient magnitude that both parties should take a good hard look in the mirror.
PS. I don't think I've ever had a post moderated four ways
Posted never by no-one
from the not-all-that-surprising dept.
Yes, remote root on recent versions of (probably) all Linux-based systems that include NFS. Fortunately, most of them seem to have issued updates already. See the Security Focus Record for a summary (and, yes, an exploit). The irony is of course that we pretend to be concerned with security, but we really care only for ridiculing Microsoft, so when something this serious hits Linux, we don't even report it.
If you are considering between Java and C++ for a large project, I'd suggest that you use C++, at least until Java has matured a bit.
If you're clever enough to come up with some other place for this ship to go, great, but otherwise cut the Sci Fi fantasizing.
You seem to have two misconceptions. First, not any group of people is a committee. A research group at a university or lab is more likely to come up with a clean solution than a team at Microsoft. Second, standardized by committee is not the same as designed by committee. The best standards codify existing (designed and implemented) practices. Even when a committee takes over maintenance of an API, they have the original design to guide them.
As for your particular examples: libc is basically what the original Unix guys wrote. C++ was designed by Stroustrup. STL was shepherded by Stepanov. SQL is shit, but we're stuck with it on all platforms. I don't know OpenGL, but good teams at start-ups often produce elegant designs. I don't know the X API, but X was designed by a research group at MIT, and for all its shortcomings has withstood time quite well.
And Perl (why do people think it's all caps?) makes my programming life worth living.
Unix is hugely legacy--but I argue that for the most part it's a good legacy! Old != bad. How much have the core Unix API had to change over the years? How much back-compatilibity does a typical Linux system support? Much less than in "API of the week" Win32 land.
And yes, Microsoft is renouned for their internal testing, but you must agree that there is a pronounced Microsoft mentality when it comes to development tools. Microsoft is a pretty self-contained culture, so I think their developers may have a hard time thinking outside that mentality. It's not a matter of the tools working "well", which I didn't dispute, it's a matter of style.
Quoth Jobs, "The think about Microsoft is, they have no taste". This rings true to me--but about the tools and API's, not the UI.
- The libraries you use are open. You can read (and marvel at or laugh at) their source code, debug them, fix them, and participate in their development communities.
- The API's you program against were mostly written by creative people with taste and community feedback; not by committees with deadlines, backwards compatibility requirements, an internal review only, and a narrow Microsoft mindset.
Really, development on a free platform is just more fun!Well, I've always thought that cell phone usage in cars is a bad idea, but on airplanes?? Pilots should certainly not be allowed to use cell phones.