Even when perl runs on a palm you won't get the whole module set--that's just too darned big. What you'll likely see is a smallish runtime that can execute perl bytecode, and that's it. You'll need to generate the bytecode elsewhere.
It's amazingly hypocritical for an organization based soley around the protections of the copyright treaties and statutes to be actively contemplating violating other people's copyrights. That the protection on PDF files is simple is doesn't justify violating the wishes of the copyright holder--the fact that it is so simple and clear makes the violation that much more egregious.
This is the equivalent of Adobe, and all the creators that generate protected PDF files, using GPL'd code and text in violation of the GPL.
Like it or not, your age will always affect how other people deal with you. Its effects can be minimized by familiarity, as other factors gain importance, but it'll never be meaningless. It's just one of those human things. (Probably a higher-mammal thing, but I'd not want to wager too heavily on that)
Its probably not just your age, though. How you present yourself makes a difference as well, though that's often a factor of how old you are--doing the Voice Of Authority takes some practice, and practice takes time as well. A firm, controlled presentation can haev a big effect on how your ideas are perceived.
Perl 6 isn't in a state to be writing books about yet. The first draft of the language design's not finished, and most of the internals design's not started yet.
I really doubt there's any mention of perl 6 in there at all. Given the standard lead time with books, it's likely this thing was set in stone before Larry even announced that perl 6 development had been set in motion.
Besides, even if it did mention per 6, there'd not be a whole lot to it. Larry's still churning away on the language spec and, while we've started designing bits of the guts that aren't dependent on that design, the guts are nowhere near designed, let alone written.
The projected public alpha's for TPC 5.0, which is in July 2001, and I don't see any reason we won't make it. We were shooting for the first full release to be about 18 months after the initial decision to do perl 6, which puts it in early 2002.
It's a big colocation facility. Lots of redundant network connections to several of the major backbones, power, 24-hour security, that sort of thing. It's the place you'd build for your own datacenter if you only had huge gobs of cash and time.
Re:Competition? There is no competition!
on
1.4-1.6 GHz Alphas
·
· Score: 1
1) Compiler quality
gcc gives good optimization on Intel chips, but its Alpha code quality isn't so great.
GCC's optimizations are definitely not up to snuff on Alphas. The Compaq C compiler, on the other hand, generates some seriously fast code and takes better advantage of the nifty tricks the Alphas play.
I wouldn't worry about code quality. Hardware drivers are definitely a different story, or course, but an EV5 or better system running code that's been compiled with EV5 optimizations will generally smoke any of the x86 chips, especially if it's more complex than plain math performance benchmarks. (The alpha's out-of-order execution stuff gets you a big win here)
Averted computer disasters are always anonymous
on
Apocalypse Not
·
· Score: 1
The biggest problem with the Y2K thing (and a lot of other looming computer disasters) is that if we do our jobs right, nobody will ever know a thing. More to the point, nobody will ever have any idea how big the problem could've been. Folks are used to 'real' disasters like hurricanes, where the threat is real and exists independent of its effects. With computer disasters (and most technology created or averted) the threat only materializes when disaster strikes.
The coolest thing about the paper is the details, such as they are, about the EV8. It's essentially four CPUs slammed together on the same chip talking to one another, and if the OS supports it you get four separate threads running at once.
This has the potential, along with a big cache, to really boost the performance of a box, as well as drop the price per bang down. SMP circuitry's not cheap or simple, and definitely non-trivial to design. But with the EV8, it's all been done for you...
Everyone seems to be confusing the AmigaOS with the Amiga hardware, and that's a big mistake. The underlying OS was a joy to program--it did shared libraries better than anything else I've seen (and I've see a lot), had a very sweet message-passing system deeply integrated, and was generally very nice. To be very blunt, the core AmigaOS is significantly better in quite a few ways than the Linux kernel. While it's too late to change things, tossing the linux core for the AmigaOS would be a bigger win than tossing the AmigaOS for linux...
If they don't follow the license (when requested), then it is stolen property. When someone violates a license anywhere by illegally copying, how is that dealt with?
Well, if what they've done violates laws and/or treaties that the country they're in has or is signatory to, then they get prosecuted as normal in that country. If what they've done isn't illegal in the country they've done it in, generally they're off the hook.
What kind of international laws apply now for stolen property? How would a case be waged if someone in China cracked a bank in the US?
I think this stuff is governed by the Berne convention and some of the other intellectual property treaties. IIRC, China is not signatory to them, in which case what they've done isn't illegal. Slimy, perhaps, but not illegal.
Are the Chinese even signatory to any of the treaties that govern these things? If they're not, then the license doesn't have any power in China (and may not in most of the world anyway) and they're not violating it.
So, M$ gets some custom Win32:: modules, and the win32 platform-specific code gets some extra stuff in it to make up for the limitations in Windows. Big deal. This is no different from the platform-specific bits for VMS, MVS, OS/2, Plan9, or half a dozen different flavors of Unix.
Anything that ActiveState puts into the core has to be covered by perl's licensing terms, so the source'll be in the main tarball. And if they really want to fork off the source tree and make changes they don't release, well, that's OK too by perl's license.
Besides, 90% of the perl people write is platform specific anyway, so who really cares? Is it so much worse to have a perl program that does Windows specific stuff than it is to have one that does something Linux specific, or VMS specific? It's not like code that plays with the registry (or/proc, or the SYSUAF) is all that portable.
Perl will remain perl regardless of what M$ might like to do to it. They've as much chance of coopting perl as they do coopting Linux.
actually linux, like most unixes is a 70's technology. WinNT is loosely based on VAX/VMS which is a 60's technology. Dragging 70's technology down to the 60's level is a disservice to everyone.
I'm afraid you've got that backwards. Unix started, more or less, in 1970, and much of its early development was done on DEC PDP machines. VMS was first released in 1978 and developed in conjunction with VAX microprocessor, which was one or two generations past the processor in the PDP systems, depending on whether you're looking at the PDP-11 or PDP-8 machines.
Both systems have seen development since, of course, though VMS in general still holds a mild technical lead over Unix in some areas. Cluster support on VMS, for example, makes the Unix and NT offerings look sad and pitiful. (If you think the FUD microsoft spews at linux is bad, try wading through the cluster MarketSpeak Micro$oft emits after comparing VMS clusters with NT 'clusters')
And yes, everyone things VMS is dead and sucks technically. That's only because Digital's Marketing department was filled with AntiMarketroids... Dec had a marketing department every bit as good as Microsoft's. Alas, they were using that skill to drive customers away, rather than keep them.
Slashdot Mirror
Even when perl runs on a palm you won't get the whole module set--that's just too darned big. What you'll likely see is a smallish runtime that can execute perl bytecode, and that's it. You'll need to generate the bytecode elsewhere.
This is the equivalent of Adobe, and all the creators that generate protected PDF files, using GPL'd code and text in violation of the GPL.
Its probably not just your age, though. How you present yourself makes a difference as well, though that's often a factor of how old you are--doing the Voice Of Authority takes some practice, and practice takes time as well. A firm, controlled presentation can haev a big effect on how your ideas are perceived.
Perl 6 isn't in a state to be writing books about yet. The first draft of the language design's not finished, and most of the internals design's not started yet.
Besides, even if it did mention per 6, there'd not be a whole lot to it. Larry's still churning away on the language spec and, while we've started designing bits of the guts that aren't dependent on that design, the guts are nowhere near designed, let alone written.
The projected public alpha's for TPC 5.0, which is in July 2001, and I don't see any reason we won't make it. We were shooting for the first full release to be about 18 months after the initial decision to do perl 6, which puts it in early 2002.
It's a big colocation facility. Lots of redundant network connections to several of the major backbones, power, 24-hour security, that sort of thing. It's the place you'd build for your own datacenter if you only had huge gobs of cash and time.
I wouldn't worry about code quality. Hardware drivers are definitely a different story, or course, but an EV5 or better system running code that's been compiled with EV5 optimizations will generally smoke any of the x86 chips, especially if it's more complex than plain math performance benchmarks. (The alpha's out-of-order execution stuff gets you a big win here)
The biggest problem with the Y2K thing (and a lot of other looming computer disasters) is that if we do our jobs right, nobody will ever know a thing. More to the point, nobody will ever have any idea how big the problem could've been. Folks are used to 'real' disasters like hurricanes, where the threat is real and exists independent of its effects. With computer disasters (and most technology created or averted) the threat only materializes when disaster strikes.
The coolest thing about the paper is the details, such as they are, about the EV8. It's essentially four CPUs slammed together on the same chip talking to one another, and if the OS supports it you get four separate threads running at once.
This has the potential, along with a big cache, to really boost the performance of a box, as well as drop the price per bang down. SMP circuitry's not cheap or simple, and definitely non-trivial to design. But with the EV8, it's all been done for you...
Everyone seems to be confusing the AmigaOS with the Amiga hardware, and that's a big mistake. The underlying OS was a joy to program--it did shared libraries better than anything else I've seen (and I've see a lot), had a very sweet message-passing system deeply integrated, and was generally very nice. To be very blunt, the core AmigaOS is significantly better in quite a few ways than the Linux kernel. While it's too late to change things, tossing the linux core for the AmigaOS would be a bigger win than tossing the AmigaOS for linux...
Are the Chinese even signatory to any of the treaties that govern these things? If they're not, then the license doesn't have any power in China (and may not in most of the world anyway) and they're not violating it.
Umm.... perl is GPL'd. And it's covered by the Artistic license as well, to avoid the viral properties and much of the nastiness of the GPL.
So, M$ gets some custom Win32:: modules, and the win32 platform-specific code gets some extra stuff in it to make up for the limitations in Windows. Big deal. This is no different from the platform-specific bits for VMS, MVS, OS/2, Plan9, or half a dozen different flavors of Unix.
/proc, or the SYSUAF) is all that portable.
Anything that ActiveState puts into the core has to be covered by perl's licensing terms, so the source'll be in the main tarball. And if they really want to fork off the source tree and make changes they don't release, well, that's OK too by perl's license.
Besides, 90% of the perl people write is platform specific anyway, so who really cares? Is it so much worse to have a perl program that does Windows specific stuff than it is to have one that does something Linux specific, or VMS specific? It's not like code that plays with the registry (or
Perl will remain perl regardless of what M$ might like to do to it. They've as much chance of coopting perl as they do coopting Linux.
actually linux, like most unixes is a 70's technology. WinNT is loosely based on VAX/VMS which is a 60's technology. Dragging 70's technology down to the 60's level is a disservice to everyone.
I'm afraid you've got that backwards. Unix started, more or less, in 1970, and much of its early development was done on DEC PDP machines. VMS was first released in 1978 and developed in conjunction with VAX microprocessor, which was one or two generations past the processor in the PDP systems, depending on whether you're looking at the PDP-11 or PDP-8 machines.
Both systems have seen development since, of course, though VMS in general still holds a mild technical lead over Unix in some areas. Cluster support on VMS, for example, makes the Unix and NT offerings look sad and pitiful. (If you think the FUD microsoft spews at linux is bad, try wading through the cluster MarketSpeak Micro$oft emits after comparing VMS clusters with NT 'clusters')
And yes, everyone things VMS is dead and sucks technically. That's only because Digital's Marketing department was filled with AntiMarketroids... Dec had a marketing department every bit as good as Microsoft's. Alas, they were using that skill to drive customers away, rather than keep them.