I don't recall exactly what has bothered me about vim in the past other than the syntax highlighting. That's always struck me as an unnatural thing for vi to do.
Why did you turn it on, then? (Given that it's off by default.)
In other words, the client can do its own compositing to produce a single UI bitmap? I guess that's possible, but realistically, how many clients will do that?
Have the applications been ported to newer hardware, or are some banks still running ancient machines based on transistors and 1st generation microchips?
It's up to the customer. That's why they love it. You can take your accounting system written in COBOL on the 360 in the 1960s, and run it in 31 bit System/360 compatibility mode on your brand new System z z10 EC machine with 64 quad-core POWER-derived processors at a speed akin to 1,500 modern x86 machines.
And if you decided to store your business information in IBM IMS in 1968, you can migrate to the new IMS version 11 on your z10 and expand your library with up to 40 TB of data.
(Opinions mine, not IBM's, and I don't work in the mainframe division.)
I've had no problems with Burnout Paradise online chat.
I've only encountered 2 asshats in Team Fortress 2 online. That said, most players don't have headsets or don't switch them on.
I've come to the conclusion that it's all about which games you play. I hear that Call of Duty has very heavy headset use, and probably lots of asshats.
See, this is why I think NoScript and CookieSafe (CS Lite) should be standard functionality in Firefox. In fact, they already have the functionality, they just need the friendly UI so normal people can actually use it.
But Mozilla won't do it, because it would piss off the advertisers who use JavaScript and cookies to surreptitiously track people. They might be an open source project, but they don't have the users' best interests at heart.
Well, that's fine--if you want to have your spreadsheet store dates in UT1 (absolute time), and provide functions to convert to and from UTC (time we actually use every day).
However, I doubt that most users would find that acceptable for a couple of reasons, the biggest being that they could save a spreadsheet, open it up a few years later, and find that the values had magically changed because a leap second had been inserted into UTC in the intervening time period.
Personally, I doubt that would be deemed better than actually storing and calculating with UTC date/time values.
Perl should have a automatic CPAN downloader that allows you to run your app and it goes and graps all those obscure modules and installs them instead of forcing me to sit there for 20 minutes typing....
In all seriousness, that's proposed for Perl 6. As per Apocalypse 12, you'll be able to do something like use Dog-{$^ver ~~ 1.2.1 | 1.3.4}-{$^auth ~~/:i jrandom/};
Agreed. I'd add that in addition, in my view Perl 6 was heading in the wrong direction.
What I wanted from Perl 6 was a cleaned-up Perl with fewer linenoisy operators, a cleaner OO programming syntax, and so on.
When I saw the Apocalypses citing code like &::('*')::($alice ~ '_misc')::Bob::doit(1,2,3) and @a =:= @b (yes, verbatim examples from Apocalypse 12), I realized that Larry Wall's idea of what makes a good programming language was fundamentally at odds with mine.
Discussing it with some unnamed senior figures in the Perl community, I was quietly informed that a lot of people were looking at Ruby. So I looked at Ruby, liked it, learned it. I've rewritten most of my Perl code as Ruby now. The result is usually about half the speed, and about 10x as readable. That, to me, is a good tradeoff.
(I wonder how many more programmers Python would get if they simply added a Ruby-like "end" keyword to end blocks with.)
You missed the point. Representing times and dates by counting units of time from an epoch is fundamentally broken, however large or small the units are. The problem is fundamental, based on the fact that the time scales we use every day cannot be extrapolated into the future indefinitely, because leap seconds occur at random.
No, tests are not documentation. For example, tests don't tell you what the extent of the supported API is--they only give you some examples that are included in the scope of the API. If all you have is tests, you have to guess whether some observed behavior is supported and intentional, or likely to go away later.
There are a lot of Ruby and Rails programmers who believe the "tests are documentation" crap, and I've seen a lot of breakage happen because of it.
Funny, my definition of legacy code is "code without documentation". If I have documentation for what the code is supposed to do, I can write tests myself. If I don't have documentation, tests won't save me.
All you need is to set up one or more truth-rating services who will publish their opinions as PICS ratings of the web sites in question.
The only thing holding up the idea is that Firefox doesn't support PICS. It's one of the few cases where Microsoft IE supports web standards better than Firefox. But no doubt that's because nobody really cares about web ratings.
(Specifically, the "problem" PICS was designed to solve was the screaming over adult content. However, once the rating system solution was deployed, it became apparent that that wasn't the solution the people screaming really wanted.)
Yes, I feel that the functionality of CS Lite and NoScript should be built in by default. I shouldn't need to go into a special mode to browse web sites I don't trust. Rather, the browser should distrust all web sites by default, unless I click an easy to find button or two to say "Yes, I trust this web site to set cookies and run scripts".
Mozilla won't do this, however, because it would piss off commercial web sites.
Slashdot Mirror
I'd take Lisp syntax over the stupidity of semantically significant indentation any day.
Dear Sun, license it under GPL3 and I'll give it a try. Otherwise, I don't see enough advantages over Linux.
Why did you turn it on, then? (Given that it's off by default.)
In other words, the client can do its own compositing to produce a single UI bitmap? I guess that's possible, but realistically, how many clients will do that?
How can rendering the font on the client and sending it to the server as a bitmap result in fewer roundtrips between client and server?
The fact that package management actually works, and is consistent from release to release, is a massive advantage over SuSE.
"Everyone use YaST... No, wait, APT4RPM... No, wait, Yum. No, let's have everyone switch to SMART. No, forget that, let's switch to zypper!"
Thanks, SuSE, I love switching package management systems.
That'll help them in their quest to be carbon-neutral won't it?
It's up to the customer. That's why they love it. You can take your accounting system written in COBOL on the 360 in the 1960s, and run it in 31 bit System/360 compatibility mode on your brand new System z z10 EC machine with 64 quad-core POWER-derived processors at a speed akin to 1,500 modern x86 machines.
And if you decided to store your business information in IBM IMS in 1968, you can migrate to the new IMS version 11 on your z10 and expand your library with up to 40 TB of data.
(Opinions mine, not IBM's, and I don't work in the mainframe division.)
I've had no problems with Burnout Paradise online chat.
I've only encountered 2 asshats in Team Fortress 2 online. That said, most players don't have headsets or don't switch them on.
I've come to the conclusion that it's all about which games you play. I hear that Call of Duty has very heavy headset use, and probably lots of asshats.
See, this is why I think NoScript and CookieSafe (CS Lite) should be standard functionality in Firefox. In fact, they already have the functionality, they just need the friendly UI so normal people can actually use it.
But Mozilla won't do it, because it would piss off the advertisers who use JavaScript and cookies to surreptitiously track people. They might be an open source project, but they don't have the users' best interests at heart.
Well, that's fine--if you want to have your spreadsheet store dates in UT1 (absolute time), and provide functions to convert to and from UTC (time we actually use every day).
However, I doubt that most users would find that acceptable for a couple of reasons, the biggest being that they could save a spreadsheet, open it up a few years later, and find that the values had magically changed because a leap second had been inserted into UTC in the intervening time period.
Personally, I doubt that would be deemed better than actually storing and calculating with UTC date/time values.
If you're going to dismiss any criticism of Perl 6 from someone who doesn't program in it, then you've dismissed *all* criticism of Perl 6. Well done.
There's a difference between a fragment of an expression in English, and what's supposed to be an entire meaningful expression in Perl.
And if you think the Perl examples are unclear and ugly because of lack of context, you have ENTIRELY missed the point.
In all seriousness, that's proposed for Perl 6. As per Apocalypse 12, you'll be able to do something like use Dog-{$^ver ~~ 1.2.1 | 1.3.4}-{$^auth ~~ /:i jrandom/};
And I wish I was joking.
Agreed. I'd add that in addition, in my view Perl 6 was heading in the wrong direction.
What I wanted from Perl 6 was a cleaned-up Perl with fewer linenoisy operators, a cleaner OO programming syntax, and so on.
When I saw the Apocalypses citing code like &::('*')::($alice ~ '_misc')::Bob::doit(1,2,3) and @a =:= @b (yes, verbatim examples from Apocalypse 12), I realized that Larry Wall's idea of what makes a good programming language was fundamentally at odds with mine.
Discussing it with some unnamed senior figures in the Perl community, I was quietly informed that a lot of people were looking at Ruby. So I looked at Ruby, liked it, learned it. I've rewritten most of my Perl code as Ruby now. The result is usually about half the speed, and about 10x as readable. That, to me, is a good tradeoff.
(I wonder how many more programmers Python would get if they simply added a Ruby-like "end" keyword to end blocks with.)
You missed the point. Representing times and dates by counting units of time from an epoch is fundamentally broken, however large or small the units are. The problem is fundamental, based on the fact that the time scales we use every day cannot be extrapolated into the future indefinitely, because leap seconds occur at random.
Representing times and dates as "seconds since epoch" is itself fundamentally broken.
ODF should use a representation that actually allows future dates to be represented with second accuracy.
No, tests are not documentation. For example, tests don't tell you what the extent of the supported API is--they only give you some examples that are included in the scope of the API. If all you have is tests, you have to guess whether some observed behavior is supported and intentional, or likely to go away later.
There are a lot of Ruby and Rails programmers who believe the "tests are documentation" crap, and I've seen a lot of breakage happen because of it.
Funny, my definition of legacy code is "code without documentation". If I have documentation for what the code is supposed to do, I can write tests myself. If I don't have documentation, tests won't save me.
I'd say there's a rather larger flaw, that you can only use Apple software and hardware.
That's why I don't buy DRMed stuff from the iTMS. I don't want to be locked into only being able to use iPods and iTunes as my music players.
All you need is to set up one or more truth-rating services who will publish their opinions as PICS ratings of the web sites in question.
The only thing holding up the idea is that Firefox doesn't support PICS. It's one of the few cases where Microsoft IE supports web standards better than Firefox. But no doubt that's because nobody really cares about web ratings.
(Specifically, the "problem" PICS was designed to solve was the screaming over adult content. However, once the rating system solution was deployed, it became apparent that that wasn't the solution the people screaming really wanted.)
Yes, I feel that the functionality of CS Lite and NoScript should be built in by default. I shouldn't need to go into a special mode to browse web sites I don't trust. Rather, the browser should distrust all web sites by default, unless I click an easy to find button or two to say "Yes, I trust this web site to set cookies and run scripts".
Mozilla won't do this, however, because it would piss off commercial web sites.
Mmm, condescension.
If you design networks to route traffic from South Africa through non-redundant links in the UK, I kinda doubt you have a job doing so.
Making it obvious that you don't know what GMT is.
GMT is defined based on astronomical observation, so there are no leap seconds needed to keep GMT noon aligned with actual noon.
The problem is with UTC, which is based on atomic clocks rather than astronomy.
Some banner ads are still available on Microsoft's web servers. Download 'em now before they're quietly deleted :-)