When we all use something like junkbuster, maybe someone will get a clue.
Then a lot of websites lose their income, and that will be the end of them - including your beloved slashdot. You *do* realize that the ads on slashdot can be used for exactly the same thing doubleclick is using them for, don't you? And I hope you've spotted the 1x1 invisible gifs on the slashdot pages as well. (Like from the nameless host 209.207.224.245).
What would be the point of going to pr0n sites in lynx, since you wouldn't be able to look at the pictures/movies?
You don't know lynx. It's missing ability to *inline* images doesn't mean it's unable to show images. All it does is using an external program, just like Netscape would do for, say, a PostScript file.
-- Abigail
Movie theaters will stay.
on
Movies Online?
·
· Score: 2
TV hasn't killed movie theaters. VCRs haven't killed them either. And I seriously doubt that the amount of people who are willing to download a 90 minute feature film to their hard disk and watch it on a 19" monitor is going to kill movie theaters.
I doubt it even will have a noticible influence in ticket sales the next 10 years.
Hopefully what will happen is the release of the solaris code will be sort of a cross-training event.
Yes, indeed. I'm a bit shocked that so many people here diss SUN because SUNs plans for making the source available doesn't fit the tunnelvision people here have of open source. Even if SUN would say "here's the source code - but keep your hands in your pockets, you can only look", it's an incredible opportunity to be taken advantage off. Solaris blows Linux out of the water when it comes to scalability, reliability and handling of heavy load. Being able to look at the source of Solaris gives others (not just Linux coders, also BSD, and even Microsoft) the opportunity to study how SUN deals with scalability and reliability issues; the gained knowledge can then be applied in your favourite OS.
From the Article: "I am happy to give someone Solaris source code and let them do whatever they want with it, if they don't use the name 'Solaris' when they are done," said Gadre. "
This sounds a lot like they want to protect their brand name more than anything else. That's understandable, given the time and money spent to create the brand name. However, managing the brand name means controlling closely the product and those who use the product. If means placing the product into certain niches and portraying it in a certain light. That's fine for a closed-source, proprietary product.
In order for open source Solaris to succeed, SUN has to be able to loosen the reins a bit and allow the community to take Solaris into places where the community feels it should go.
Let me get this straight. Sun is opening up the source of Solaris, and saying to the world "do whatever you want to do with it, just don't label it Solaris", and you still whine?. Not even Bill Gates is that arrogant. Have you written Knuth already? He has the same condition for the source of TeX. And do contact Larry Wall to complain as well, as one of the options of the Artistic License is renaming the resulting binary if you take the source code and with it what you wish.
SUN, if it really wants to release Solaris as open source, should require distributers to place their company names in front of it such that we'll see things as "SUN Solaris", "Red Hat Solaris" or "PPC Solaris" In that way we'll always be able to evaluate and distinguish between different releases.
And that's to SUNs benefit how? It would be a severe disadvantage to SUN. They either have to give up the connection between Solaris and Sun (which from a marketing viewpoint would be incredibly stupid), or have to deal with all the problems introduced by outside coders (which would be incredibly stupid from both a marketing and technical viewpoint.)
Solaris shines in some areas Linux hardly dares to dream about. SUN says "Here's the code. Study it. Learn from it. Use it. Just don't call the thing you use it in Solaris." And instead of grabbing the opportunity, you whine.
Realism. It was refreshing to see a Sci-Fi that didn't glaze over things like breathing in space, and acceleration (well, mostly)
Hahahahaha. It was a universe where sound waves were transmitted through space (the captain went to "silent mode"; colliding ice crystals made sound), where stopping your engines would make you move at the same speed as objects in your environment (whatever it is that transmitted sound also provided friction I guess), where there is a lot of ambient light all around (how else do you have all the reflections in the ice field?), and where gravity is universal (except when not having gravity is needed for a particular scene), providing a distinct "down".
but AE had pure energy life forms
Ah, something that Star Trek has every other week. Not really original anymore. (And why on earth does pure energy take the form of humanoids and needs separate space ships (and how can pure energy ships be blown up?))
I'm willing to accept alternative universes, with different laws of nature - just don't sell it as "realism".
How about a brand new protocol for locating documents on httpds?
Most of the suggested ideas for this "protocol" are already part of of the HTTP protocol.
WHERE/baz.html
Not at all needed. That is basically what HTTP does. The URL name space is just a name space. The only relationship between a URL and a file is whatever is dictated by local policy.
100/baz.html
That's basically the 200 HTTP status code.
101/baz/1.html 102 http://foo.baz.org/bar.html
HTTP doesn't make a needless difference between moved to the same server or a different server. It does however make a difference between moved permanently and moved temporarily. Status codes 301 and 302.
103 KILLED
Status code 410.
200 DOESNT EXIST
Status code 404.
300 SERVER ERROR
That's the 5xx category of status codes. There are also the 4xx status codes, if the problem is with the request itself.
Maybe, also, there should be another client command, SEARCH, to find any/all occurances of a file name, like: SEARCH bar.html
That doesn't make sense to put in a protocol, as URLs do *not* point to files. An HTTP server *might* map it to a file, but that's outside the domain of the URL name space. Furthermore, since the URL name space is infinite, the result of such a search command could be an infinite list as well. However, it's isn't hard to put in such a functionality in your HTTP server. For instance, the server can be instructed to do a search when encountering the request for/SEARCH/bar.html.
And a directory list, too... Client says: LIST/
Again, that doesn't fit in the current standards for the same reason. But note that many HTTP servers have this feature already.
I have begun to write this all up. Anyone who wants to help, visit my web site, find my e-mail address, and tell me you wish to help with this protocol.
I strongly suggest you won't trouble yourself in making the effort. You start with the wrong idea, that URLs map to files, and most of the requested functionality is already been taken care of in the HTTP standard.
It shouldn't be too difficult to write a short script that would check all the links on one's web site periodically.
That will only check outbound links. That's not the problem what's being solved. The problem is checking for inbound links. That is, links on other peoples websites to your website. That isn't easily solved with a short script.
This one is definitely "geared" more toward math majors and actual practicing mathematicians instead of the aveage slashdot geek
Eh, I don't know where you went to school, but the math in this article doesn't go beyond high school levels. At least not on where I went to high school.
I'm not sure what you mean by the average slashdot geek. Just because it doesn't mention Linux or free software doesn't mean it ain't interesting.
A burger or pancake machine won't cost nowhere as much as a robotic arm.
What makes arms so special that they can be reprogrammed, but box shaped machines can't?
The article didn't say anything about it being able to cook much anything that fits on the grill. Burgers and pancakes are very uniform, not only from unit to unit, but very uniform in a single unit as well. Just because it can flip burgers doesn't mean it can fry eggs or onions.
The article didn't mention cleaning up at night. All it did was removing some grease from the plate between cookings. If that's all the cleaning you do at night, the health department will shut you down very quickly.
What's so special about the arm that it is modular and upgradable, but a machine that doesn't mimic a human arm isn't?
I rather have the cheap, small burger machine in the corner, with a redundant one next to it, than a big expensive, immobile, moving piece of iron imitating a human arm in the middle of the kitchen.
I don't know about you, but I'd actually pay extra for a burger that was prepared "untouched by human hands".
But this machine only cooks the burgers. It doesn't butcher the cow. It doesn't grind the meat. It doesn't make them into patties. It doesn't pack the patties in a box. It doesn't make the bun. It doesn't put the meat on the bun. It doesn't cut the lettuce, tomato or onion. It doesn't assemble the burger.
Untouched by human hands seems nice - but Flipper doesn't make that happen.
Take a look at fast-food nowadays. New items are continuously being added and removed from the menu. Having flexibility in the cook to make those new items is an incredible advantage.
When was the last time you went to McDonalds or Burgerking that they didn't have hamburgers or fries? Some items may appear or disappear, but one of the key things in the success of fast-food chains is their uniformity *and* the fact it doesn't change much. Fries are there to stay. Burgers are there to stay.
The value in using this particular arm design is that it can be fitted into the existing kitchen without a redesign as it simply acts as another person.
Yes, but robots don't. I seriously doubt a large fraction of the current fast food kitchens have room for an inmobile robot in front of the griddle. Not only does the robot take at least as much space as a human, there will also be a safety zone where people should not enter when the robot is in operation; some safety laws might even demand the robot automatically shuts down when someone gets too close.
And you maintain the ability for a person to take over for a few hours if the robot fails and needs to be repaired.
With a big dead hump of metal in front of the griddle? Where's the person supposed to stand?
I suspect that's a bit cheaper than most employees, with no other costs.
No other costs? How do you supposed the robot runs? Magic? There are lots and lots of other costs:
Power.
Maintenance.
Repairs.
Cleaning (not just of the robot, but also of the rest of the kitchen; you don't want to be shut down by the health department).
Supplying (the robot doesn't walk to the delivery truck and takes the boxes of meat).
Construction (the robot plus griddle/oven won't fit in your kitchen as it is now).
And then of course you still need people to help the customers, to assemble the burgers and all other stuff that's needed to actually feed the customer. OTOH, an employee making $X/hour costs the employer a lot more than $X/hour. Think insurance, health plans, 401k, training, management, etc.
And even then most linux viruses can do little more than delete your home directory,
I don't know what you do with your computer, but on my systems, user files are far, far more important than system files. I can restore/usr/bin/sh from media, and/vmlinuz by downloading the source and recompiling it. All it takes is a little time, but I would almost be able to do it blindfolded.
A thesis someone has been working on for four years, a program you've spend the previous month working on around the clock or a carefully worked picture from the GIMP have to be restored from the last successful backup - if any.
Granted, system files are important on important 24x7 servers - but you wouldn't be using them to read mail on in the first place, would you?
found it very amusing seeing as I use Pine and Netscape to read mail and neither one could give two hoots about VB script.
That's only partially true. Many Unix mailreaders, including Netscape and mutt (and probably Pine) use a config file to figure out what to do with attachments - $HOME/.mailcap is a fairly standard file for that; but it can also be set up system wide. It's also being used by browsers in the same way. It's fairly trivial to configure it do something with a VB script, although on a Unix platform VB interpreters will not be very common. But Perl, python, tcl and shells are common. And it takes only one line in a single config file to have browsers and mailers of all users execute a Perl program on an application/perl mime type. (Or Python, or tcl, or whatever)
Email virusses isn't a matter of that can only happen on Windows. It happens only on Windows because Windows is far more popular than Unix. But if more and more less computer literate people move from Windows to Unix, more and more tools out of the box configured with everything turned out will appear on Unix. Including mailers that will happely try to run a program in whatever language you send them. Just look for instance at all the services Joe Q. RedHatUser has running on his Linux box.
Of course, you might argue that Unix has permissions, and users cannot delete system files. But that's details. The most important files on a computer are user files, not system files. A system can usually trivially be replaced; just re-install it from your orginal media, and run your install scripts. Companies often have an install server to make it even more easy. But user files have added value. They are the product of work. At best, they can be restored from backup, but even then there's a loss.
To sum up, the reason virusses aren't a problem on Unix is the popularity of Windows.
What if the dialectizer were a program that you ran on your computer that translated the pages? It would be perfectly okay, right? Now what's the difference between that and running the program off of someone elses computer to be sent back to you?
That's the same issue as you cannot video tape something from television, and rebroadcast it, while showing it in your own home, for a small audience, is fine. Neither can you buy a CD and broadcast it over the radio without paying for the rights. Even if the CD was free of charge.
The difference is that rinkworks is serving (that is, they are publicating it) the translated pages, and not the original creators.
Really? If I write a class, and publish the interface, and you want to use it, how do you know it does data hiding without poking through the source?
Perl isn't a write-only language you know. It's also about using someone elses code. And Perl OO doesn't make that easy at all.
Conway shows in his book what the full toolkit of OO techniques is--you can then select what you need for the job.
Indeed. Write once, use once. Perl OO doesn't at all stimulate code reuse. Any implementation of a class greatly influences how derived classes have to be implemented. That's fine if you want to start from scratch for each project, or are willing to deal with the bagage on a next project. But it doesn't stimulate you to write clean code.
-- Abigail
Re:OO is for representing things as objects.
on
Object Oriented Perl
·
· Score: 2
You could do that if you want, to.
Yes, I know Perl lets you have that. I know Perl very well. And as I said before, I know that if you do a lot of work, you can have implementation hiding and data encapsulation. But you didn't understand my point.
Once again: Perl is making easy things easy, and hard things possible. But within an OO framework, implementation hiding and data encapsulation should be easy. Doing everything with AUTOLOAD and dispatch tables isn't easy. It's hard work!
Whatever floats your boat!
Indeed. Keyword: your. OO is about code reuse. Someone elses code. But, since Perl lets you make objects in a myriad of ways, and makes the implementation part of the API, whether you want it or not, Perl is unsuited as an OO language.
You cannot treat the implementation as a black box and only look at the public API. Yes you can - use a tied hash interface and everything suddenly has to go through an access function! Not awkward in the least.
See, there you said it. use a tied hash. If I want to inherit someone elses class (that's what OO is about, code reuse, remember), and that someone uses just a hash reference (like almost everyone does), you're screwed. That's what I mean with you cannot treat the implementation as a black box. Saying yes you can if it was implemented this and this way is just proving my point; not disproving it.
-- Abigail
Re:OO is for representing things as objects.
on
Object Oriented Perl
·
· Score: 2
As for data encapsulation, which is OO, how does perl's OO not do this?
Simple. The typical way (yes, I know how it can be done differently, but let's just ignore the 1% code out there that does it actually different) of making a Perl object is with a blessed hash reference. All your variables associated with that object are put in a hash reference.
Now you want to inherit a class with such an object. Where are you going to put your variables? Right. In the same hash reference. No data encapsulation. No implementation hiding. No private variables.
Or to summerize it: no OO.
Data hiding is simply a matter of public vs. private APIs. You anounce your public API, you don't anounce your private API, and you make the distinction that anyone using the private API gets what they deserve.
The problem is, with Perl, to be able to successful inherit someone elses class, you have to know how the class implements objects. You cannot treat the implementation as a black box and only look at the public API.
Hence, no real OO.
If you really can't trust your programmers enough to follow the rules, make the damn thing a tcp/ip server or a corba service.
It has nothing to do with trust. It has everything to do with programming convenience. I want to be able to take something, obey its API, and then, regardless of what I do, I should not be able to accidentely trample on someones elses variables, or be forced to implement classes the same way as the inherited class was implemented. But the language doesn't give that to me by default; only if I'm lucky and use something whose author went to great trouble keeping their space clean I can do that.
Again, yes, I know it's possible. Damians book shows it's possible. The problem is, Perl's OO is so awkward, it ain't happening. And that's the language fault - not the programmers.
So you are blaming the language for the faults of the people who use it? (ie being lazy).
In this case, yes. Perl wants the programmer to be lazy. But the lazy way to do OO in Perl is using blessed hash references (and 99% of the examples and code out there uses blessed hash references).
And closures aren't really so hard as I would call them "bending over backwards".
I have no problem using closures. Perhaps you might want to look at my OO::Closures package on CPAN that does OO without using bless (and has full data encapsulation and implementation hiding). However, use of closures for objects is extremely rare - apparently it's too difficult for 99.99% of the Perl coders out there.
Besides...not everyone cares about black boxen. OOP is nice, if thats what you like.
Well, if you don't want to use OO, there's no point in discussing here. My point is that if you want to use OO, Perl isn't a suitable language. 99% of the code that's labelled as OO in Perl is nothing more than abstract datatypes with weak binding. It ain't OO; a '->' token doesn't make OO.
You don't like PERL...don't use it.
Well, it's Perl, not PERL. And I do like Perl. I just don't like the monster they call OO-Perl, because it's neither Perl, nor OO.
No Data Hiding? Not fammiliar with closures are you? They make it quite easy to hide your data.
Care to point out a module in the Perl standard library that uses closures for objects? Or a well known CPAN package?
I hear it all the time. Sure, with Perls OO you can do foo. It's easy! Just bend over backwards this way. Except that noone does it. So, you still can't use someone elses black box, cause noone finds it easy enough to make their box black.
After reading this book, I not only understand the principals but I can use them. I am now looking at OO'ng all my code now. It makes sense!
Oh, please.
Damians book is a great book. It shows the real face of Perl OO. How horrible it is. How utterly useless. How it is against both OO principles and Perl principles. Granted, for people who don't know what OO is, or have no experience, Perls OO looks great. But for people who want to use OO for the reasons OO is there: data encapsulation and implementation hiding, Damian clearly shows all the hoops, whistles and bells you need to do yourself before you can do so. In fact, to do real data encapsulation and implementation hiding, you have to do so much work yourself that nothing that comes with Perl standard libraries implements this. Nothing. Nada. Zilch.
Perls OO is like MacDonalds food. Fast, cheap, and great if you aren't used to anything else. Kids love it. But utterly disgusting for lovers of gourmet food.
From that viewpoint, allowing people to use the software in non-free software programs is sitting back and allowing them to screw the public out of what is there right.
What right? The previous poster came with the example of FreeBSD and MacOS X. What right was taken away from the public because Apple created MacOS X? The right to FreeBSD? No, that's still available. The right to MacOS X? Where would the rights of the public come from? Would the public also had had the rights to that OS if Apple would not have written MacOS X?
Slashdot Mirror
I've done that years ago. Tom Christiansen has made the tarball available for that, somewhere on perl.com.
-- Abigail
Then a lot of websites lose their income, and that will be the end of them - including your beloved slashdot. You *do* realize that the ads on slashdot can be used for exactly the same thing doubleclick is using them for, don't you? And I hope you've spotted the 1x1 invisible gifs on the slashdot pages as well. (Like from the nameless host 209.207.224.245).
-- Abigail
You don't know lynx. It's missing ability to *inline* images doesn't mean it's unable to show images. All it does is using an external program, just like Netscape would do for, say, a PostScript file.
-- Abigail
I doubt it even will have a noticible influence in ticket sales the next 10 years.
-- Abigail
Yes, indeed. I'm a bit shocked that so many people here diss SUN because SUNs plans for making the source available doesn't fit the tunnelvision people here have of open source. Even if SUN would say "here's the source code - but keep your hands in your pockets, you can only look", it's an incredible opportunity to be taken advantage off. Solaris blows Linux out of the water when it comes to scalability, reliability and handling of heavy load. Being able to look at the source of Solaris gives others (not just Linux coders, also BSD, and even Microsoft) the opportunity to study how SUN deals with scalability and reliability issues; the gained knowledge can then be applied in your favourite OS.
-- Abigail
This sounds a lot like they want to protect their brand name more than anything else. That's understandable, given the time and money spent to create the brand name. However, managing the brand name means controlling closely the product and those who use the product. If means placing the product into certain niches and portraying it in a certain light. That's fine for a closed-source, proprietary product.
In order for open source Solaris to succeed, SUN has to be able to loosen the reins a bit and allow the community to take Solaris into places where the community feels it should go.
Let me get this straight. Sun is opening up the source of Solaris, and saying to the world "do whatever you want to do with it, just don't label it Solaris", and you still whine?. Not even Bill Gates is that arrogant. Have you written Knuth already? He has the same condition for the source of TeX. And do contact Larry Wall to complain as well, as one of the options of the Artistic License is renaming the resulting binary if you take the source code and with it what you wish.
SUN, if it really wants to release Solaris as open source, should require distributers to place their company names in front of it such that we'll see things as "SUN Solaris", "Red Hat Solaris" or "PPC Solaris" In that way we'll always be able to evaluate and distinguish between different releases.
And that's to SUNs benefit how? It would be a severe disadvantage to SUN. They either have to give up the connection between Solaris and Sun (which from a marketing viewpoint would be incredibly stupid), or have to deal with all the problems introduced by outside coders (which would be incredibly stupid from both a marketing and technical viewpoint.)
Solaris shines in some areas Linux hardly dares to dream about. SUN says "Here's the code. Study it. Learn from it. Use it. Just don't call the thing you use it in Solaris." And instead of grabbing the opportunity, you whine.
Words fail to describe that attitude.
-- Abigail
Hahahahaha. It was a universe where sound waves were transmitted through space (the captain went to "silent mode"; colliding ice crystals made sound), where stopping your engines would make you move at the same speed as objects in your environment (whatever it is that transmitted sound also provided friction I guess), where there is a lot of ambient light all around (how else do you have all the reflections in the ice field?), and where gravity is universal (except when not having gravity is needed for a particular scene), providing a distinct "down".
but AE had pure energy life forms
Ah, something that Star Trek has every other week. Not really original anymore. (And why on earth does pure energy take the form of humanoids and needs separate space ships (and how can pure energy ships be blown up?))
I'm willing to accept alternative universes, with different laws of nature - just don't sell it as "realism".
-- Abigail
Most of the suggested ideas for this "protocol" are already part of of the HTTP protocol.
WHERE /baz.html
Not at all needed. That is basically what HTTP does. The URL name space is just a name space. The only relationship between a URL and a file is whatever is dictated by local policy.
100 /baz.html
That's basically the 200 HTTP status code.
101 /baz/1.html
102 http://foo.baz.org/bar.html
HTTP doesn't make a needless difference between moved to the same server or a different server. It does however make a difference between moved permanently and moved temporarily. Status codes 301 and 302.
103 KILLED
Status code 410.
200 DOESNT EXIST
Status code 404.
300 SERVER ERROR
That's the 5xx category of status codes. There are also the 4xx status codes, if the problem is with the request itself.
Maybe, also, there should be another client command, SEARCH, to find any/all occurances of a file name, like: SEARCH bar.html
That doesn't make sense to put in a protocol, as URLs do *not* point to files. An HTTP server *might* map it to a file, but that's outside the domain of the URL name space. Furthermore, since the URL name space is infinite, the result of such a search command could be an infinite list as well. /SEARCH/bar.html.
However, it's isn't hard to put in such a functionality in your HTTP server. For instance, the server can be instructed to do a search when encountering the request for
And a directory list, too... Client says: LIST /
Again, that doesn't fit in the current standards for the same reason. But note that many HTTP servers have this feature already.
I have begun to write this all up. Anyone who wants to help, visit my web site, find my e-mail address, and tell me you wish to help with this protocol.
I strongly suggest you won't trouble yourself in making the effort. You start with the wrong idea, that URLs map to files, and most of the requested functionality is already been taken care of in the HTTP standard.
Ref: RFC 2068
-- Abigail
That will only check outbound links. That's not the problem what's being solved. The problem is checking for inbound links. That is, links on other peoples websites to your website. That isn't easily solved with a short script.
-- Abigail
Eh, I don't know where you went to school, but the math in this article doesn't go beyond high school levels. At least not on where I went to high school.
I'm not sure what you mean by the average slashdot geek. Just because it doesn't mention Linux or free software doesn't mean it ain't interesting.
-- Abigail
I rather have the cheap, small burger machine in the corner, with a redundant one next to it, than a big expensive, immobile, moving piece of iron imitating a human arm in the middle of the kitchen.
-- Abigail
But this machine only cooks the burgers. It doesn't butcher the cow. It doesn't grind the meat. It doesn't make them into patties. It doesn't pack the patties in a box. It doesn't make the bun. It doesn't put the meat on the bun. It doesn't cut the lettuce, tomato or onion. It doesn't assemble the burger.
Untouched by human hands seems nice - but Flipper doesn't make that happen.
-- Abigail
When was the last time you went to McDonalds or Burgerking that they didn't have hamburgers or fries? Some items may appear or disappear, but one of the key things in the success of fast-food chains is their uniformity *and* the fact it doesn't change much. Fries are there to stay. Burgers are there to stay.
-- Abigail
Yes, but robots don't. I seriously doubt a large fraction of the current fast food kitchens have room for an inmobile robot in front of the griddle. Not only does the robot take at least as much space as a human, there will also be a safety zone where people should not enter when the robot is in operation; some safety laws might even demand the robot automatically shuts down when someone gets too close.
And you maintain the ability for a person to take over for a few hours if the robot fails and needs to be repaired.
With a big dead hump of metal in front of the griddle? Where's the person supposed to stand?
-- Abigail
No other costs? How do you supposed the robot runs? Magic? There are lots and lots of other costs:
- Power.
- Maintenance.
- Repairs.
- Cleaning (not just of the robot, but also of the rest of the kitchen; you don't want to be shut down by the health department).
- Supplying (the robot doesn't walk to the delivery truck and takes the boxes of meat).
- Construction (the robot plus griddle/oven won't fit in your kitchen as it is now).
And then of course you still need people to help the customers, to assemble the burgers and all other stuff that's needed to actually feed the customer. OTOH, an employee making $X/hour costs the employer a lot more than $X/hour. Think insurance, health plans, 401k, training, management, etc.-- Abigail
I don't know what you do with your computer, but on my systems, user files are far, far more important than system files. I can restore /usr/bin/sh from media, and /vmlinuz by downloading the source and recompiling it. All it takes is a little time, but I would almost be able to do it blindfolded.
A thesis someone has been working on for four years, a program you've spend the previous month working on around the clock or a carefully worked picture from the GIMP have to be restored from the last successful backup - if any.
Granted, system files are important on important 24x7 servers - but you wouldn't be using them to read mail on in the first place, would you?
-- Abigail
That's only partially true. Many Unix mailreaders, including Netscape and mutt (and probably Pine) use a config file to figure out what to do with attachments - $HOME/.mailcap is a fairly standard file for that; but it can also be set up system wide. It's also being used by browsers in the same way. It's fairly trivial to configure it do something with a VB script, although on a Unix platform VB interpreters will not be very common. But Perl, python, tcl and shells are common. And it takes only one line in a single config file to have browsers and mailers of all users execute a Perl program on an application/perl mime type. (Or Python, or tcl, or whatever)
Email virusses isn't a matter of that can only happen on Windows. It happens only on Windows because Windows is far more popular than Unix. But if more and more less computer literate people move from Windows to Unix, more and more tools out of the box configured with everything turned out will appear on Unix. Including mailers that will happely try to run a program in whatever language you send them. Just look for instance at all the services Joe Q. RedHatUser has running on his Linux box.
Of course, you might argue that Unix has permissions, and users cannot delete system files. But that's details. The most important files on a computer are user files, not system files. A system can usually trivially be replaced; just re-install it from your orginal media, and run your install scripts. Companies often have an install server to make it even more easy. But user files have added value. They are the product of work. At best, they can be restored from backup, but even then there's a loss.
To sum up, the reason virusses aren't a problem on Unix is the popularity of Windows.
Let's keep it that way.
-- Abigail
That's the same issue as you cannot video tape something from television, and rebroadcast it, while showing it in your own home, for a small audience, is fine. Neither can you buy a CD and broadcast it over the radio without paying for the rights. Even if the CD was free of charge.
The difference is that rinkworks is serving (that is, they are publicating it) the translated pages, and not the original creators.
-- Abigail
Really? If I write a class, and publish the interface, and you want to use it, how do you know it does data hiding without poking through the source?
Perl isn't a write-only language you know. It's also about using someone elses code. And Perl OO doesn't make that easy at all.
Conway shows in his book what the full toolkit of OO techniques is--you can then select what you need for the job.
Indeed. Write once, use once. Perl OO doesn't at all stimulate code reuse. Any implementation of a class greatly influences how derived classes have to be implemented. That's fine if you want to start from scratch for each project, or are willing to deal with the bagage on a next project. But it doesn't stimulate you to write clean code.
-- Abigail
Yes, I know Perl lets you have that. I know Perl very well. And as I said before, I know that if you do a lot of work, you can have implementation hiding and data encapsulation. But you didn't understand my point.
Once again: Perl is making easy things easy, and hard things possible. But within an OO framework, implementation hiding and data encapsulation should be easy. Doing everything with AUTOLOAD and dispatch tables isn't easy. It's hard work!
Whatever floats your boat!
Indeed. Keyword: your. OO is about code reuse. Someone elses code. But, since Perl lets you make objects in a myriad of ways, and makes the implementation part of the API, whether you want it or not, Perl is unsuited as an OO language.
You cannot treat the implementation as a black box and only look at the public API. Yes you can - use a tied hash interface and everything suddenly has to go through an access function! Not awkward in the least.
See, there you said it. use a tied hash. If I want to inherit someone elses class (that's what OO is about, code reuse, remember), and that someone uses just a hash reference (like almost everyone does), you're screwed. That's what I mean with you cannot treat the implementation as a black box. Saying yes you can if it was implemented this and this way is just proving my point; not disproving it.
-- Abigail
Simple. The typical way (yes, I know how it can be done differently, but let's just ignore the 1% code out there that does it actually different) of making a Perl object is with a blessed hash reference. All your variables associated with that object are put in a hash reference.
Now you want to inherit a class with such an object. Where are you going to put your variables? Right. In the same hash reference. No data encapsulation. No implementation hiding. No private variables.
Or to summerize it: no OO.
Data hiding is simply a matter of public vs. private APIs. You anounce your public API, you don't anounce your private API, and you make the distinction that anyone using the private API gets what they deserve.
The problem is, with Perl, to be able to successful inherit someone elses class, you have to know how the class implements objects. You cannot treat the implementation as a black box and only look at the public API.
Hence, no real OO.
If you really can't trust your programmers enough to follow the rules, make the damn thing a tcp/ip server or a corba service.
It has nothing to do with trust. It has everything to do with programming convenience. I want to be able to take something, obey its API, and then, regardless of what I do, I should not be able to accidentely trample on someones elses variables, or be forced to implement classes the same way as the inherited class was implemented. But the language doesn't give that to me by default; only if I'm lucky and use something whose author went to great trouble keeping their space clean I can do that.
Again, yes, I know it's possible. Damians book shows it's possible. The problem is, Perl's OO is so awkward, it ain't happening. And that's the language fault - not the programmers.
-- Abigail
In this case, yes. Perl wants the programmer to be lazy. But the lazy way to do OO in Perl is using blessed hash references (and 99% of the examples and code out there uses blessed hash references).
And closures aren't really so hard as I would call them "bending over backwards".
I have no problem using closures. Perhaps you might want to look at my OO::Closures package on CPAN that does OO without using bless (and has full data encapsulation and implementation hiding). However, use of closures for objects is extremely rare - apparently it's too difficult for 99.99% of the Perl coders out there.
Besides...not everyone cares about black boxen. OOP is nice, if thats what you like.
Well, if you don't want to use OO, there's no point in discussing here. My point is that if you want to use OO, Perl isn't a suitable language. 99% of the code that's labelled as OO in Perl is nothing more than abstract datatypes with weak binding. It ain't OO; a '->' token doesn't make OO.
You don't like PERL...don't use it.
Well, it's Perl, not PERL. And I do like Perl. I just don't like the monster they call OO-Perl, because it's neither Perl, nor OO.
-- Abigail
Care to point out a module in the Perl standard library that uses closures for objects? Or a well known CPAN package?
I hear it all the time. Sure, with Perls OO you can do foo. It's easy! Just bend over backwards this way. Except that noone does it. So, you still can't use someone elses black box, cause noone finds it easy enough to make their box black.
-- Abigail
Oh, please.
Damians book is a great book. It shows the real face of Perl OO. How horrible it is. How utterly useless. How it is against both OO principles and Perl principles. Granted, for people who don't know what OO is, or have no experience, Perls OO looks great. But for people who want to use OO for the reasons OO is there: data encapsulation and implementation hiding, Damian clearly shows all the hoops, whistles and bells you need to do yourself before you can do so. In fact, to do real data encapsulation and implementation hiding, you have to do so much work yourself that nothing that comes with Perl standard libraries implements this. Nothing. Nada. Zilch.
Perls OO is like MacDonalds food. Fast, cheap, and great if you aren't used to anything else. Kids love it. But utterly disgusting for lovers of gourmet food.
-- Abigail
What right? The previous poster came with the example of FreeBSD and MacOS X. What right was taken away from the public because Apple created MacOS X? The right to FreeBSD? No, that's still available. The right to MacOS X? Where would the rights of the public come from? Would the public also had had the rights to that OS if Apple would not have written MacOS X?
-- Abigail