> Pick up a book. I'm not trying to be snide; I > think you're going to find much more of the kind > of inventiveness you're looking for in sci-fi > novels than you ever will in the movies.
What, you think I got all those ideas without reading?:)
As well as The Reality Dysfunction (+The Neutronium Alchemist and The Naked God), I can also heartily recommend Eon (+Eternity and Legacy) and Queen of Angels (+Slant and Moving Mars).
> I think it's just a limitation of the > television / movie medium. Well, not of the > medium, but of the economic circumstances > driving the medium.
It's the same with games; same old FPS' with slightly nicer graphics and a different cheesy storyline, or RTS clones, or, um.. er..
I suppose the best we can hope for is an evolution, where the industries try similar concepts in different ways and move slowly between different ones. As we get richer, maybe we'll see more turnover and them being a bit more prepared to try new things.
> With insanely powerful weapons comes instant destruction.
Not really; with insanely powerful weapons comes equally powerful defense; launch a volly of missiles at someone, they launch a bunch back, fire a beam of radiation at someone, they fire a cloud of reflective chaff back and disapate the heat (or hiding behind the huge cloud of radiation your missiles (and by missiles, think: semi-intelligent minature warships with submunitions, big, dirty drive systems that cloud everything etc)).
Soldiers get smart "skins" which solidify and conduct excess heat into the ground, meaning it takes nothing short of a direct hit to kill them (not to mention the boosted bodies which are more capable of taking damage).
It doesn't always become more instant (even when it does, nobody's going to want to fry ground forces from orbit, just like nobody now wants (or can arrange) to start throwing nukes around), since both sides won't be standing still.
> A massive confrontation like this unfortunately leaves little room for personal interaction.
Nope; you're not going to make a film entirely out of that, there's plenty of room for getting across the raw panic/cold determinism/etc of the people involved, then you've got space for setting up these huge battles, all the politics and interpersonal relationships that caused them etc, then the after effects as people risk their lives to save survivors. And of course, you've got the more mundane aspects of the lives of the main characters.
Really, you're not going to make a movie entirely out of that sort of large scale battle; they're probably not going to last long anyway (how long do you think anyone would survive these sort of battles without either being vaporised, running out of ammo, overheating or deciding to run away?), and nobody's going to go about nuking planets/space stations/each other without good reason. You might as well say the same about any movie; sure, done badly it'll end up being a special effects showcase and nothing else, but hey, it's not going to be any worse than what we already have, is it?
Right, big ships, a few explosions and some dodgy gunk-cum-plasma firing guns.
When are we going to see films that really capture the true scale of the energy levels we're going to be flinging around? I don't want to see ships throwing primary coloured blobs at each other, I want to see them fling high yield nukes, antimatter weapons that light up the sky and threaten to melt any surface nearby, I want to see missiles that fill space with incandescent plasma that fades before being blown appart as it's lanced by otherwise invisible beams of radiation.
I want to see acceleration an issue; I want to see people who couldn't get to a chair to scream in agony as they get crushed down by high G forces or get torn to bits by decompressions, not a few panels exploding and some lame shaking.
I want to see ground troops frying acres of land as they desperately try to kill an enemy, I want to see them blowing shit up with gauss guns and worryingly powerful antimatter devices, or proper ray guns where you only see what's reflected off dust and things they're melting/frying (and which cause the atmosphere to explode like lightning). Screw phasers.
I want to see believable universes, filled with Humans for a change; no humanoid "aliens" who happen to act like certain stereotypes (aliens will, of course, get a look in, but not as human analogs ffs); there's huge scope for different cultures, technologies, types of people and things people will become (from tweaked to entirely redesigned) that you get with humans alone without having to think up Unlikely Stereotypical Alien-with-ridged-forehead-and-attitude-problem 31338.
Of course, it's not going to happen.. tried and tested paper thin plots and people and a few shiny special effects is just too damn easy to throw together and make money out of.
<fume>
rc system
on
NetBSD 1.5ZB
·
· Score: 4, Interesting
NetBSD's got a very nice rc (startup) system; as opposed to the monolithic (Open|Free)BSD approach, NetBSD's is a highly modular dependancy based model; no more giving scripts esoteric names like "000.wibble" to try to get it executed before "001.wobble"; just add a dependency in wobble on wibble and the rc system will make sure wibble is executed first.
The syntax is nice and clean and the object model is lovely. The C API is rather good too; C/ObjC/C++ extensions often end up looking rather like Ruby.
HTTP is designed to be cached; for example, the Vary: header lets the cache know what to cache based on; in this case it'd be Content-Encoding.
Squid may well be smart enough to know to cache documents with two different Content-Encoding's as different entities, but if not you just add Vary: Content-Encoding so it does.
(that, at least, is the theory, I'm afraid I can't claim to have read the entire HTTP 1.1 spec, tsk:)
> Almost all of those arguments... can be used in discussing the Unix shell environment vs the Macintosh Finder.
And Explorer, except they at least do it in an environment where it's suitable and manage to do so with what's actually fairly trivial resources (well, let's ignore some of the more, um, advanced features like integrated media player/browser etc for now).
Frankly, I'd be more impressed if instead of going 3D (or adding built in media players, or intergrating Zip) for the k00l factor, they introduced or reused things in 2D that made it more powerful or intuitive; they are the aims of a user interface, after all, not how-to-add-another-gimick.
Having the large and flexible toolkit of the Unix shell environment still manages to massively overpower current graphical environments; why don't people try to introduce such concepts to them? You've probably got a similar chance of producing something usable as a 3D environment, but you'll probably learn a lot more (assuming you're wanting to hone your UI skills rather than 3D ones:)
(NB: For "They", read "people who write file managers" and not "the specific people who wrote this 3D file manager":)
I didn't say it wasn't "cool" or didn't look good, I said it's not a good or interesting file manager concept. Every 6 months one pops up, but none of them seem bothered with becoming a serious usable application.
Anyway, if people can write useless utilities for fun I can say they're useless and suggest something even more useless and fun:P
So, for 100x the CPU and memory usage, I can see fewer of my files at once, and do less with them, and have them represented in a totally unintuitive and unfamiliar way?
Right, that's very good. What next? Text editors with words represented as different coloured 11 dimensional hypercubes?:)
Good idea. There are so many technologies that could be used in a way that obfuscates sites; Flash, JavaScript, DHTML, tables, tag soup, box model abuse etc; unfortunately I suspect some existing and popular sites may well prove too hard to beat.
Still, could serve as a nice ironic way to point out why avoiding and abusing standards is Bad[tm].
> What follows is my commentary as I tried to get this post under the lameness filter -- resulting in the useless shit post you see above.
Ugh, yeah, the lameness filter truely is the most evil bit of code Mr Taco ever made/approved. Probably.
At the very least it should be turned off (or tuned down significantly) for users with lots of karma; if I get to post at +2 I think it's also reasonable to expect I'm not going to post ASCII penis birds etc.
A few weeks ago I wrote a nice little comment that was mostly a list of points; obviously liking to get proper formatting I threw in the required HTML and was instantly hit by the lameness filter, basically making the HTML formatted mode entirely useless.
And yes, I admit, my train of thought wasn't entirely different from yours:)
(said HTML mode also removes a lot of useful HTML I like to use; titles for links in order to describe what I'm linking to better, <abbr> and <acronym> which are nice when using a lot of TLA's and ETLA's, <small> which is useful for notes and something I might even have used for this piece of text, etc. Yet I'm allowed to use elements like <div> that have pretty much zero use? Blegh)
JVM is aimed more at static strongly typed languages (well, language); Perl and it's ilk are much more dynamic and like to do things that would make Java want to kill itself.
Still, work is going on to make use of the JVM (I believe the JRuby guys were talking about that), and there's talk of Java bytecode/Parrot bytecode converters, but JVM isn't really made with that in mind.
> Finally, a web-server scripting environment giving you all the features you always missed, like > coredumps, buffer overflows and format string errors
Yup, open source web software finally catches up with Microsoft. Should go nicely with the FreeBSD.NET port:)
> (just what is the non-proprietary vector animation standard, anyway?)
SVG, or Scalable Vector Graphics, which also includes a mobile version and also caters for disabled users and non standard display devices.
There are tools to author it such as Jasc WebDraw, and it can be displayed on a significant proportion of browsers (IE is the only browser I know supports it, Mozilla probably does too).
Good point, although it's still a good idea to look at your data from a PoV that doesn't include PHP, otherwise you end up doing what phpWiki does and having a database full of serialize()d PHP objects you can't even concider touching outside PHP.
> As long as we're making a list, let's add its lack of multi-threading. Drives me crazy!
Thread.start(socket.accept) do |socket|
socket.send("Moo!") end
Ah Ruby, how I love thee, let me count the ways.. er.. I mean.. *cough*
> And I'd love to use private methods.
Private member variables were recently added to Zend 2, although really this just means the variable $this->Bla isn't the same as $otherobject->Bla; internally the name is changed, so there's no error messages, just a different variable.
One more way you can make your programs difficult to maintain:)
This nasty behavior was chosen because it's pretty much free; the name is changed at compile time. Obviously a new field in the symbol table and an if() check is way too much to ask of Zend.
> It's memory usage is also spotty. For one-second web scripts, this doesn't matter so much.
Actually, since it's embedded, and since Apache likes to keep memory hanging around, this can be a problem; if your script allocates, say, 70MB once, the httpd process will sit at that level even if it sticks to more sane amounts in future.
That's what --enable-memory-limit is for, though.
> But for long-running apps, I've had trouble.
I'd say that's outside PHP's problem domain, and it should stay that way; the only advantage of being able to use PHP outside the webserver is the ability to not learn anything else, but all that does is give you the language equivilent of in-breeding, and we all know what that does..
PHP has finally moved (in CVS, anyway) to installing a command-line interpreter in all installations now, so unfortunately (or fortunately, depending on your point of view) there's now even less reason for 100,000 naive PHP users to learn a different language and give them a more rounded perspective.
> Seems like the perfect time for BSD to enter the 21st century.
Actually, FreeBSD seems to be moving more towards Win2k-style ACPI support in -CURRENT (although that's more of a gut-feeling[tm] than a hard fact; I'm sure someone else can elaborate)
Aside from flaky hardware (which you can turn off in most cases), this is a Good Thing, although you can be sure you'll be able to turn it off in FreeBSD if the need arrises.
I said base, as in, the language it is primarily aimed for, with other languages having to be sufficiently like it to fit in.
Luckily the reference implimentations for the other languages Parrot wants to support aren't going away, so I doubt it's going to pull a "VB.Net = VB#" type thing.NET is alleged to be doing.
Perl 6 should be rather more interesting; it'll be a completely new architecture, with the Perl itself parsed by, um, Perl (5), which will then generate bytecode for the semi-language-independent bytecode engine Parrot, which will execute it (and let the Perl5 'compiler' migrate and become self hosting).
This will allow Perl to concentrate on developing the language rather than the engine that drives it, and even better, let other languages in on the act; want to write your own little language and want it to run anywhere *and* use Perl modules? Code to Parrot bytecode.
This extends to other languages; Python and Ruby bods seem to take it quite seriously, so even if your admins refuse to install $flavour_of_the_month language, you can still grab the backend in Parrot bytecode and target your scripts to Parrot.
And, being Perl, it's sure to end up everywhere. That is, assuming they every actually come up with something that works before the Universe ends:)
* waits for someone to compare it to.NET, only with Perl as the base language rather than C#
I'm afraid it's not changed much from that state, although some work is going into fixing some of it's biggest failings.
The object model is being improved significantly in <a href="http://www.zend.org/zend/future.php">Zend Engine 2</a> (Zend being what powers PHP4), with namespaces (implimented as nested classes you pretend you can't instantiate), and object handles rather than hacks on the hash implimentation. It still lacks nice features like iterators, but it is at least moving in the right direction.
The shove-everything-in-the-default-namespace mentality is still there, meaning you either code functionally or write OO wrappers for everything (not to mention how bloated it becomes; when used for standalone apps, having it driven by a binary that's linked to to pretty much everything kinda looses it's appeal).
Keywords are still unusable anywhere; you can't have methods called Print(), or Import(), not even if you fully qualify them (maybe I'm spoilt by Ruby:)
The dodgy case sensitivity issues are still there; functions are not case sensitive, variables are (hence you can't use Print() in a class, despite the keyword being print). With the new object model where you can just use methodCall() instead of $this->methodCall() I can see this biting people more in future.
(include|require)_once are still there, and are the usual way to include any file; that's 4 statements that do pretty much the same thing, with the longer uglier ones being the most common. A Perlish 'use Package::Module::Class' statement may help here, although it's only just being discussed seriously.
The language still lacks any real specification; features are added and removed on the whims of the developers, occasionally based on the feedback from users, who sometimes miss obvious problems with changes until it's worryingly late.
On the plus side, they do take backward compatibility fairly seriously and aren't always afraid to break it to introduce badly wanted new features (hence case sensitivity is an unlikely candidate to be changed, but the new OO model might break things).
At the end of the day, I wouldn't use it for anything other than web stuff; the language simply isn't that good. The biggest plus point is it's truely kickass server embedding support, but beyond that there are much better alternatives.
> I bet Google will come out with a "show as HTML" options for Flash sites.
Is that really possible? Is there enough metadata in Flash to turn an entirely graphical oriented flash file into (fairly) plain text?
I doubt Google would be too pleased if the only HTML analog is tonnes of JavaScript and PNG's, or even SVG, which despite it's open nature isn't as accessible as Flash (yet).
Slashdot Mirror
> Pick up a book. I'm not trying to be snide; I
:)
> think you're going to find much more of the kind
> of inventiveness you're looking for in sci-fi
> novels than you ever will in the movies.
What, you think I got all those ideas without reading?
As well as The Reality Dysfunction (+The Neutronium Alchemist and The Naked God), I can also heartily recommend Eon (+Eternity and Legacy) and Queen of Angels (+Slant and Moving Mars).
> I think it's just a limitation of the
> television / movie medium. Well, not of the
> medium, but of the economic circumstances
> driving the medium.
It's the same with games; same old FPS' with slightly nicer graphics and a different cheesy storyline, or RTS clones, or, um.. er..
I suppose the best we can hope for is an evolution, where the industries try similar concepts in different ways and move slowly between different ones. As we get richer, maybe we'll see more turnover and them being a bit more prepared to try new things.
> Read a book.
> Hollywood isn't ready for that yet.
Well, it is still fairly "early"; who knows what will happen in the next few years/decades/centuries.
> I recommend the Hyperion series.
The Reality Dysfunction series is rather good too. Peter Hamilton++;
Not sure how it got to +4, +3 is the best I count (maybe you have a +1 modifier on Insightful comments?) but since you asked:
:)
"Insightful" (+1)
"Troll" (-1)
"Interesting" (+1)
"Flamebait" (-1)
"Interesting" (+1)
"Overrated" (-1)
This is why we have metamoderation
> With insanely powerful weapons comes instant destruction.
Not really; with insanely powerful weapons comes equally powerful defense; launch a volly of missiles at someone, they launch a bunch back, fire a beam of radiation at someone, they fire a cloud of reflective chaff back and disapate the heat (or hiding behind the huge cloud of radiation your missiles (and by missiles, think: semi-intelligent minature warships with submunitions, big, dirty drive systems that cloud everything etc)).
Soldiers get smart "skins" which solidify and conduct excess heat into the ground, meaning it takes nothing short of a direct hit to kill them (not to mention the boosted bodies which are more capable of taking damage).
It doesn't always become more instant (even when it does, nobody's going to want to fry ground forces from orbit, just like nobody now wants (or can arrange) to start throwing nukes around), since both sides won't be standing still.
> A massive confrontation like this unfortunately leaves little room for personal interaction.
Nope; you're not going to make a film entirely out of that, there's plenty of room for getting across the raw panic/cold determinism/etc of the people involved, then you've got space for setting up these huge battles, all the politics and interpersonal relationships that caused them etc, then the after effects as people risk their lives to save survivors. And of course, you've got the more mundane aspects of the lives of the main characters.
Really, you're not going to make a movie entirely out of that sort of large scale battle; they're probably not going to last long anyway (how long do you think anyone would survive these sort of battles without either being vaporised, running out of ammo, overheating or deciding to run away?), and nobody's going to go about nuking planets/space stations/each other without good reason. You might as well say the same about any movie; sure, done badly it'll end up being a special effects showcase and nothing else, but hey, it's not going to be any worse than what we already have, is it?
Right, big ships, a few explosions and some dodgy gunk-cum-plasma firing guns.
When are we going to see films that really capture the true scale of the energy levels we're going to be flinging around? I don't want to see ships throwing primary coloured blobs at each other, I want to see them fling high yield nukes, antimatter weapons that light up the sky and threaten to melt any surface nearby, I want to see missiles that fill space with incandescent plasma that fades before being blown appart as it's lanced by otherwise invisible beams of radiation.
I want to see acceleration an issue; I want to see people who couldn't get to a chair to scream in agony as they get crushed down by high G forces or get torn to bits by decompressions, not a few panels exploding and some lame shaking.
I want to see ground troops frying acres of land as they desperately try to kill an enemy, I want to see them blowing shit up with gauss guns and worryingly powerful antimatter devices, or proper ray guns where you only see what's reflected off dust and things they're melting/frying (and which cause the atmosphere to explode like lightning). Screw phasers.
I want to see believable universes, filled with Humans for a change; no humanoid "aliens" who happen to act like certain stereotypes (aliens will, of course, get a look in, but not as human analogs ffs); there's huge scope for different cultures, technologies, types of people and things people will become (from tweaked to entirely redesigned) that you get with humans alone without having to think up Unlikely Stereotypical Alien-with-ridged-forehead-and-attitude-problem 31338.
Of course, it's not going to happen.. tried and tested paper thin plots and people and a few shiny special effects is just too damn easy to throw together and make money out of.
<fume>
NetBSD's got a very nice rc (startup) system; as opposed to the monolithic (Open|Free)BSD approach, NetBSD's is a highly modular dependancy based model; no more giving scripts esoteric names like "000.wibble" to try to get it executed before "001.wobble"; just add a dependency in wobble on wibble and the rc system will make sure wibble is executed first.
There's an interesting PDF paper on the design and implimentation, some conciderably more terse and less interesting official documentation and a Daemon News article, and for those uber geeks, the CVS repository where you can compare with the other BSD's.
You'll note FreeBSD -CURRENT is looking at adopting it, while Open sticks with the tried and tested BSD4.4-type setup
> python even has gui bindings for windows
I'm not sure about native Win32 GUI stuff, but Ruby certainly has some pretty decent OLE support.
There's also support for native DLL API calls, and a free downloadable book (Programming Ruby).
The syntax is nice and clean and the object model is lovely. The C API is rather good too; C/ObjC/C++ extensions often end up looking rather like Ruby.
You can grab Win32 binaries from http://www.pragmaticprogrammer.com/, which includes a nice selection of bundled modules.
HTTP is designed to be cached; for example, the Vary: header lets the cache know what to cache based on; in this case it'd be Content-Encoding.
:)
Squid may well be smart enough to know to cache documents with two different Content-Encoding's as different entities, but if not you just add Vary: Content-Encoding so it does.
(that, at least, is the theory, I'm afraid I can't claim to have read the entire HTTP 1.1 spec, tsk
> Almost all of those arguments ... can be used in discussing the Unix shell environment vs the Macintosh Finder.
:)
:)
And Explorer, except they at least do it in an environment where it's suitable and manage to do so with what's actually fairly trivial resources (well, let's ignore some of the more, um, advanced features like integrated media player/browser etc for now).
Frankly, I'd be more impressed if instead of going 3D (or adding built in media players, or intergrating Zip) for the k00l factor, they introduced or reused things in 2D that made it more powerful or intuitive; they are the aims of a user interface, after all, not how-to-add-another-gimick.
Having the large and flexible toolkit of the Unix shell environment still manages to massively overpower current graphical environments; why don't people try to introduce such concepts to them? You've probably got a similar chance of producing something usable as a 3D environment, but you'll probably learn a lot more (assuming you're wanting to hone your UI skills rather than 3D ones
(NB: For "They", read "people who write file managers" and not "the specific people who wrote this 3D file manager"
I didn't say it wasn't "cool" or didn't look good, I said it's not a good or interesting file manager concept. Every 6 months one pops up, but none of them seem bothered with becoming a serious usable application.
:P
Anyway, if people can write useless utilities for fun I can say they're useless and suggest something even more useless and fun
So, for 100x the CPU and memory usage, I can see fewer of my files at once, and do less with them, and have them represented in a totally unintuitive and unfamiliar way?
:)
Right, that's very good. What next? Text editors with words represented as different coloured 11 dimensional hypercubes?
> Let's see some obfuscated Ruby programs.
From Tomasz Wegrzanowski ([ruby-talk:30377]):
$\=(?c??d:?e).chr+%Q%\n%;$,=%q=o, =;;%q{leHrow}=~/(...)(...)/;print [$1,$2].map{|l|l.reverse+%q|l|}
Showing the more Perlish side of Ruby.
I recall seeing one that calculated Pi with code of a similar quality too, along with a few quines, although I'm yet to seen an obfuscated one.
> International Obfuscated Website Contest
Good idea. There are so many technologies that could be used in a way that obfuscates sites; Flash, JavaScript, DHTML, tables, tag soup, box model abuse etc; unfortunately I suspect some existing and popular sites may well prove too hard to beat.
Still, could serve as a nice ironic way to point out why avoiding and abusing standards is Bad[tm].
> What follows is my commentary as I tried to get this post under the lameness filter -- resulting in the useless shit post you see above.
:)
Ugh, yeah, the lameness filter truely is the most evil bit of code Mr Taco ever made/approved. Probably.
At the very least it should be turned off (or tuned down significantly) for users with lots of karma; if I get to post at +2 I think it's also reasonable to expect I'm not going to post ASCII penis birds etc.
A few weeks ago I wrote a nice little comment that was mostly a list of points; obviously liking to get proper formatting I threw in the required HTML and was instantly hit by the lameness filter, basically making the HTML formatted mode entirely useless.
And yes, I admit, my train of thought wasn't entirely different from yours
(said HTML mode also removes a lot of useful HTML I like to use; titles for links in order to describe what I'm linking to better, <abbr> and <acronym> which are nice when using a lot of TLA's and ETLA's, <small> which is useful for notes and something I might even have used for this piece of text, etc. Yet I'm allowed to use elements like <div> that have pretty much zero use? Blegh)
JVM is aimed more at static strongly typed languages (well, language); Perl and it's ilk are much more dynamic and like to do things that would make Java want to kill itself.
Still, work is going on to make use of the JVM (I believe the JRuby guys were talking about that), and there's talk of Java bytecode/Parrot bytecode converters, but JVM isn't really made with that in mind.
> Finally, a web-server scripting environment giving you all the features you always missed, like
.NET port :)
> coredumps, buffer overflows and format string errors
Yup, open source web software finally catches up with Microsoft. Should go nicely with the FreeBSD
> (just what is the non-proprietary vector animation standard, anyway?)
SVG, or Scalable Vector Graphics, which also includes a mobile version and also caters for disabled users and non standard display devices.
There are tools to author it such as Jasc WebDraw, and it can be displayed on a significant proportion of browsers (IE is the only browser I know supports it, Mozilla probably does too).
Good point, although it's still a good idea to look at your data from a PoV that doesn't include PHP, otherwise you end up doing what phpWiki does and having a database full of serialize()d PHP objects you can't even concider touching outside PHP.
> As long as we're making a list, let's add its lack of multi-threading. Drives me crazy!
:)
Thread.start(socket.accept) do |socket|
socket.send("Moo!")
end
Ah Ruby, how I love thee, let me count the ways.. er.. I mean.. *cough*
> And I'd love to use private methods.
Private member variables were recently added to Zend 2, although really this just means the variable $this->Bla isn't the same as $otherobject->Bla; internally the name is changed, so there's no error messages, just a different variable.
One more way you can make your programs difficult to maintain
This nasty behavior was chosen because it's pretty much free; the name is changed at compile time. Obviously a new field in the symbol table and an if() check is way too much to ask of Zend.
> It's memory usage is also spotty. For one-second web scripts, this doesn't matter so much.
Actually, since it's embedded, and since Apache likes to keep memory hanging around, this can be a problem; if your script allocates, say, 70MB once, the httpd process will sit at that level even if it sticks to more sane amounts in future.
That's what --enable-memory-limit is for, though.
> But for long-running apps, I've had trouble.
I'd say that's outside PHP's problem domain, and it should stay that way; the only advantage of being able to use PHP outside the webserver is the ability to not learn anything else, but all that does is give you the language equivilent of in-breeding, and we all know what that does..
PHP has finally moved (in CVS, anyway) to installing a command-line interpreter in all installations now, so unfortunately (or fortunately, depending on your point of view) there's now even less reason for 100,000 naive PHP users to learn a different language and give them a more rounded perspective.
> Seems like the perfect time for BSD to enter the 21st century.
Actually, FreeBSD seems to be moving more towards Win2k-style ACPI support in -CURRENT (although that's more of a gut-feeling[tm] than a hard fact; I'm sure someone else can elaborate)
Aside from flaky hardware (which you can turn off in most cases), this is a Good Thing, although you can be sure you'll be able to turn it off in FreeBSD if the need arrises.
http://www.jp.freebsd.org/acpi/ seems to be about the best page I can find on this.
> .NET's intermediate language isn't C#
.NET is alleged to be doing.
I said base, as in, the language it is primarily aimed for, with other languages having to be sufficiently like it to fit in.
Luckily the reference implimentations for the other languages Parrot wants to support aren't going away, so I doubt it's going to pull a "VB.Net = VB#" type thing
Perl 6 should be rather more interesting; it'll be a completely new architecture, with the Perl itself parsed by, um, Perl (5), which will then generate bytecode for the semi-language-independent bytecode engine Parrot, which will execute it (and let the Perl5 'compiler' migrate and become self hosting).
:)
.NET, only with Perl as the base language rather than C#
This will allow Perl to concentrate on developing the language rather than the engine that drives it, and even better, let other languages in on the act; want to write your own little language and want it to run anywhere *and* use Perl modules? Code to Parrot bytecode.
This extends to other languages; Python and Ruby bods seem to take it quite seriously, so even if your admins refuse to install $flavour_of_the_month language, you can still grab the backend in Parrot bytecode and target your scripts to Parrot.
And, being Perl, it's sure to end up everywhere. That is, assuming they every actually come up with something that works before the Universe ends
* waits for someone to compare it to
I'm afraid it's not changed much from that state, although some work is going into fixing some of it's biggest failings.
:)
The object model is being improved significantly in <a href="http://www.zend.org/zend/future.php">Zend Engine 2</a> (Zend being what powers PHP4), with namespaces (implimented as nested classes you pretend you can't instantiate), and object handles rather than hacks on the hash implimentation. It still lacks nice features like iterators, but it is at least moving in the right direction.
The shove-everything-in-the-default-namespace mentality is still there, meaning you either code functionally or write OO wrappers for everything (not to mention how bloated it becomes; when used for standalone apps, having it driven by a binary that's linked to to pretty much everything kinda looses it's appeal).
Keywords are still unusable anywhere; you can't have methods called Print(), or Import(), not even if you fully qualify them (maybe I'm spoilt by Ruby
The dodgy case sensitivity issues are still there; functions are not case sensitive, variables are (hence you can't use Print() in a class, despite the keyword being print). With the new object model where you can just use methodCall() instead of $this->methodCall() I can see this biting people more in future.
(include|require)_once are still there, and are the usual way to include any file; that's 4 statements that do pretty much the same thing, with the longer uglier ones being the most common. A Perlish 'use Package::Module::Class' statement may help here, although it's only just being discussed seriously.
The language still lacks any real specification; features are added and removed on the whims of the developers, occasionally based on the feedback from users, who sometimes miss obvious problems with changes until it's worryingly late.
On the plus side, they do take backward compatibility fairly seriously and aren't always afraid to break it to introduce badly wanted new features (hence case sensitivity is an unlikely candidate to be changed, but the new OO model might break things).
At the end of the day, I wouldn't use it for anything other than web stuff; the language simply isn't that good. The biggest plus point is it's truely kickass server embedding support, but beyond that there are much better alternatives.
> I bet Google will come out with a "show as HTML" options for Flash sites.
Is that really possible? Is there enough metadata in Flash to turn an entirely graphical oriented flash file into (fairly) plain text?
I doubt Google would be too pleased if the only HTML analog is tonnes of JavaScript and PNG's, or even SVG, which despite it's open nature isn't as accessible as Flash (yet).