They are both touched.
In the msnbc.com one, you can see that the front underside of the tank has been retouched using the 'rubber stamp' tool. I'm not sure what's been removed, but it might be a piece of equipment.
It seems that the boy was genuinely there, though. The shadows match.
In the milanet.ie one, the boy has been removed. You can tell because the armored plates and cables that are along the front of the tank don't match up anymore.
Additionally, there is some false shadowing on the underside of the gun barrel that I can't explain.
I'm not sure that's a US tank, by the way.
Additionally, there is a lot of resistance to open-source solutions in the network administrations on college campuses. Most colleges have Novell or Windows based infrastructure everywhere but the science and computer/engineering schools.
Instead of rolling your own, check for software others have written. OpenACS is a good start, but there's tons more. Search Freshmeat.
...Verisign isn't trying to change the name; someone faxed forms with fake signatures in, and the temps just processed the forms without checking them. Next, Verisign will have to go through a dispute process to get its corporate name back.
Re:Merits of PHP compared to Perl?
on
Professional PHP4
·
· Score: 1
We have this argument at work all the time.;)
The big deciding factor is what you'll use it for. If you just want to display dynamic web pages, PHP will be easier and faster in most cases than Perl ever will.
If you need to do a ton of weird crap, Perl is probably your best bet. Same thing if you have to do a ton of character translations and regexp-ing.
The big difference between Perl and PHP is that Perl is easy to learn in its simplicty, but can get incredibly weird as you get into the expert levels... to the point where a beginning coder can't figure out what the fsck Mr. Joe Camel, Perl Wizard, was smoking when he wrote that bit of code. OTOH, it can do a lot more.
PHP is pretty much limited to basic browser web interfaces. It's amazingly easy to learn and program, and a lot of things that are moderately difficult to do with Perl are easy in PHP. PHP code that does complex and weird things is also fairly easy to read and understand. OTOH, it is very limited, but it's very good at what it's limited to.
PHP is a great tool for web development. Perl is commonly referred to as a "Swiss Army Chainsaw", because it can do just about anything you want it to do, but it's almost always overkill.
That being said, you should explore HTML Mason just a little bit if you like Perl but want the equivalent of PHP in Perl.
The PHP website offers several relatively small windows help files that you can download and keep on your hard drive... if you want, it'll even display user comments. That way, you don't have to always be connected to the web while you're coding.
A business will always choose a fixed cost over a variable cost. But there's many points of view.
From a system administrator's point of view: I work in the data processing indstury, and we have a 12-way NUMA box as our mainframe. We moved from a 16-way SE-70 that we'd had for seven years earlier this year, and our software has already expanded to max out the capacity of the new NUMA unit - to the point where we've upgraded it several times.
We'd continue to expand if the perception was that we have unlimited resources.
From a business point of view: Even if we could do our dp activities on someone else's mainframe, we would still have our system administration costs for systems that can't be moved out of the building, so our costs don't go down. We would also have to maintain in-house development machines, because we wouldn't want to pay someone else for the endless compiles that we would need while developing new software. Additionally, we already have a huge, unamortized investment in fixed dp assets. Currently, our systems process for 24 hours per day to meet our needs. If we were to do these same activities on a metered system, we would probably not have to process as long, but if costs are over $5,000 per month metered, it's not worth it, especially since there are no cost savings except for the cost of amoritization of our main hardware.
Corporations buy unmetered data lines because they don't want to have to deal with variable (and, in case of a slashdotting, extremely high and exteremely unstable) costs. Trying to sell a service that has a variable cost structure is good for a company, but buying a service that has a variable cost structure is bad for a company. The only time buying becomes good is when the company can't provide it for itself, as with electrical power and telecom. But it's easy to buy/build your own mainframe-class computer for less than $10,000.
Wow, slow for you? I've got a p3 600 and a hunka burnin' RAM, and it's blazing fast for me. Using tabbed browsing and not having to open another window saves me lightyears every day over IE.
Oh, I'll definately admit that browser programmers are doing poor jobs. Mozilla is the best we've got, and it's still not great.
"NS 4 is broken. It just happens to be the least broken right now."
Actually, I'd say that NS4 is pretty damned broken. And as for displaying the content in NS4 - it still displays, doesn't it? Check out www.alistapart.com.
PHP can support DTDs simply by echoing something that looks like
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
(That's funny, didn't realize that Slashdot was written to full 3.2... thought it was 4.0 strict at least...) at the very start of the document. It's a piece of HTML, not something that PHP needs to process. That's all web standards are, a specific way of writing HTML or any other web markup language in a way that all processors can understand it... not something that takes a lot of time and effort to implement, but still cripples a site. (Now NS 4 support on the other hand, takes a lot of time to implement and can cripple a site.. or at least a developer, from having to write their javascript twice! But I digress.)
No, but you have different expectations for linuxhomepage.com than I do for the site of the company I work for. XHTML/CSS are presentation subsets of the language. Also, you do not specify a DTD, so what are you going to do when a new browser comes along, using XHTML 1.0-strict (which expects a separation between style and content) and makes your toothpicked, bgcolored tables obsolete? Times, languages, and standards change.
My point was that designers DO design for the middle. XHTML 1.0 and CSS are standards designed to be ACCESSIBLE in all browsers and devices, and the PRESENTATION elements are phased in as browsers and devices can support them. Dialup is very much still a reality in the US, and that -is- the middle, which means we should design for it. Are you saying that everything should look the same as your site? How boring.
Standards-compliant DOM engines, XHTML-1.0 and CSS allow sites to be legible in a wider variety of browsers than HTML 4.0 and inline styles with browser-war era broken DOMs ever did.
So how are designers supposed to produce brochure-ware sites (remember, it's not the designers who are dictating it looks good, it's the pointy-haired bosses) that look good on the CEO's cousin's computer out in West BFE on a 28.8 modem and AOL?
There are several strategies. The first is to address the colors issue -- the web palette. By using the standard web palette, designers can try to match their background and text colors to colors that anyone with a 256 color graphics card/monitor can see. It's useless to try and do this for images, but the graphics card will dither that anyway.
The second is by reducing the page weight and the number of files that need to be reloaded. That's one of the things that XHTML and CSS is about. The average page weight on a page full of data after I converted our corporate intranet to XHTML 1.0 Trans and linked stylesheets was 10k, down from approximately 60-70k using a table-and-graphic-based layout. By using stylesheets and commonly available fonts or alternatives, designers can come close to ensuring that their site will be visible the way that it is intended to look (including fonts) on the widest variety of computers that are likely to be in use to visit the website. It's very unlikely these days that someone will be surfing the web with a 16-color display. Text-only (lynx) is more likely, but modern standards take that into account and simply hide the stylesheet from those computers. If the designer is worth his salt, the website will still display fully.
Unfortunately, it takes way too long to download a PDF with embedded images on a 28.8 modem out in West BFE. The CEO's cousin won't be happy, and neither will the CEO, which means the designer will lose his job. Which gets your theory nowhere.
18 point times new roman (Windows default for h1 text) really screws with your brochureware site if you don't style it to something more appropriate to your site. I guess I don't understand what you're saying - you imply that consistent look and feel is a drug that webmasters are on that they need to get off of; but also that consistent look and feel has failed because of webmasters?
Zeldman responded to a lot of the points brought up before in this MetaFilter Thread. (This story is about a week old.)
What Mr. Zeldman is promoting is forwards-compatibility. The traffic for 4.x browsers is finally receeding; most people (thanks to AOL or Windows upgrades) are on IE 5.x+. If you write your sites so that they're still readable in 4.x, even if they don't look good, that's good enough. (Explaining to PHB's that it would take three times the time it's already taken you to code for 4.x also helps, even if it's stretching it a bit.) What you need to look at is foward compatibility. It's like programming for APIs - you knew that the API calls for win95 weren't going to go away and break your code in 98. Well, the tag formats for XHTML-1.0Trans and CSS 1.0 won't break in the future. That's why we have standards.
You are incorrect that the Sentra CA is the only SULEV vehicle on the road. Honda Accord EX-L's and all hybrids are registered as SULEV in California, and indeed, the air coming out of the tailpipe of an Accord EX-L is cleaner than the air going in the intake.
Re:Buethundr's guide to Collecting Okudagrams
on
Trek Prop Collecting
·
· Score: 1
Ah, Bluethundr - All the information about in-jokes you just gave is also in the ST:TNG tech manual. I'm really curious to see if you've got pictures with closeups of these things -- I never quite belevied the manual!
Slashdot Mirror
Best way to get stories actually posted -- submit a duplicate!
And now, the new head of the avian agriculture department... the big bad wolf!
They are both touched. In the msnbc.com one, you can see that the front underside of the tank has been retouched using the 'rubber stamp' tool. I'm not sure what's been removed, but it might be a piece of equipment. It seems that the boy was genuinely there, though. The shadows match. In the milanet.ie one, the boy has been removed. You can tell because the armored plates and cables that are along the front of the tank don't match up anymore. Additionally, there is some false shadowing on the underside of the gun barrel that I can't explain. I'm not sure that's a US tank, by the way.
A buddy of mine is building an automatic alcohol dispenser that's controlled via a paralell port and relays. Here's his schematics section.
Eh, it's /forms/ ... s plural. Not /form/
Am I smoking crack, or is that NetSaint/Nagios to the picture to the left of the globe???
Additionally, there is a lot of resistance to open-source solutions in the network administrations on college campuses. Most colleges have Novell or Windows based infrastructure everywhere but the science and computer/engineering schools.
Instead of rolling your own, check for software others have written. OpenACS is a good start, but there's tons more. Search Freshmeat.
...Verisign isn't trying to change the name; someone faxed forms with fake signatures in, and the temps just processed the forms without checking them. Next, Verisign will have to go through a dispute process to get its corporate name back.
We have this argument at work all the time. ;)
The big deciding factor is what you'll use it for. If you just want to display dynamic web pages, PHP will be easier and faster in most cases than Perl ever will.
If you need to do a ton of weird crap, Perl is probably your best bet. Same thing if you have to do a ton of character translations and regexp-ing.
The big difference between Perl and PHP is that Perl is easy to learn in its simplicty, but can get incredibly weird as you get into the expert levels... to the point where a beginning coder can't figure out what the fsck Mr. Joe Camel, Perl Wizard, was smoking when he wrote that bit of code. OTOH, it can do a lot more.
PHP is pretty much limited to basic browser web interfaces. It's amazingly easy to learn and program, and a lot of things that are moderately difficult to do with Perl are easy in PHP. PHP code that does complex and weird things is also fairly easy to read and understand. OTOH, it is very limited, but it's very good at what it's limited to.
PHP is a great tool for web development. Perl is commonly referred to as a "Swiss Army Chainsaw", because it can do just about anything you want it to do, but it's almost always overkill.
That being said, you should explore HTML Mason just a little bit if you like Perl but want the equivalent of PHP in Perl.
The PHP website offers several relatively small windows help files that you can download and keep on your hard drive... if you want, it'll even display user comments. That way, you don't have to always be connected to the web while you're coding.
How would people be able to filter out what's signal and what's just plain noise?
Wasn't this part of the Command & Conquer plot? When will the tiberium fields start growing around these trees?
A business will always choose a fixed cost over a variable cost. But there's many points of view.
From a system administrator's point of view:
I work in the data processing indstury, and we have a 12-way NUMA box as our mainframe. We moved from a 16-way SE-70 that we'd had for seven years earlier this year, and our software has already expanded to max out the capacity of the new NUMA unit - to the point where we've upgraded it several times.
We'd continue to expand if the perception was that we have unlimited resources.
From a business point of view:
Even if we could do our dp activities on someone else's mainframe, we would still have our system administration costs for systems that can't be moved out of the building, so our costs don't go down. We would also have to maintain in-house development machines, because we wouldn't want to pay someone else for the endless compiles that we would need while developing new software.
Additionally, we already have a huge, unamortized investment in fixed dp assets.
Currently, our systems process for 24 hours per day to meet our needs. If we were to do these same activities on a metered system, we would probably not have to process as long, but if costs are over $5,000 per month metered, it's not worth it, especially since there are no cost savings except for the cost of amoritization of our main hardware.
Corporations buy unmetered data lines because they don't want to have to deal with variable (and, in case of a slashdotting, extremely high and exteremely unstable) costs. Trying to sell a service that has a variable cost structure is good for a company, but buying a service that has a variable cost structure is bad for a company. The only time buying becomes good is when the company can't provide it for itself, as with electrical power and telecom. But it's easy to buy/build your own mainframe-class computer for less than $10,000.
Since when did Slashdot start posting free advertisements from corporations .. I mean, anonymous readers, for the corporation's product... ?
Wasn't there a SeaQuest DSV where the boy genius hacked the hackers that were trying to hack the Brasillian elections?
"Have you ever seen a fat tiger?"
No, but I've never seen Joe Sixpack chase a zebra and kill it with his teeth, either.
Wow, slow for you? I've got a p3 600 and a hunka burnin' RAM, and it's blazing fast for me. Using tabbed browsing and not having to open another window saves me lightyears every day over IE.
Oh, I'll definately admit that browser programmers are doing poor jobs. Mozilla is the best we've got, and it's still not great.
"NS 4 is broken. It just happens to be the least broken right now."
Actually, I'd say that NS4 is pretty damned broken. And as for displaying the content in NS4 - it still displays, doesn't it? Check out www.alistapart.com.
PHP can support DTDs simply by echoing something that looks like
(That's funny, didn't realize that Slashdot was written to full 3.2... thought it was 4.0 strict at least...) at the very start of the document. It's a piece of HTML, not something that PHP needs to process. That's all web standards are, a specific way of writing HTML or any other web markup language in a way that all processors can understand it... not something that takes a lot of time and effort to implement, but still cripples a site. (Now NS 4 support on the other hand, takes a lot of time to implement and can cripple a siteNo, but you have different expectations for linuxhomepage.com than I do for the site of the company I work for. XHTML/CSS are presentation subsets of the language. Also, you do not specify a DTD, so what are you going to do when a new browser comes along, using XHTML 1.0-strict (which expects a separation between style and content) and makes your toothpicked, bgcolored tables obsolete? Times, languages, and standards change.
My point was that designers DO design for the middle. XHTML 1.0 and CSS are standards designed to be ACCESSIBLE in all browsers and devices, and the PRESENTATION elements are phased in as browsers and devices can support them. Dialup is very much still a reality in the US, and that -is- the middle, which means we should design for it. Are you saying that everything should look the same as your site? How boring.
Standards-compliant DOM engines, XHTML-1.0 and CSS allow sites to be legible in a wider variety of browsers than HTML 4.0 and inline styles with browser-war era broken DOMs ever did.
So how are designers supposed to produce brochure-ware sites (remember, it's not the designers who are dictating it looks good, it's the pointy-haired bosses) that look good on the CEO's cousin's computer out in West BFE on a 28.8 modem and AOL? There are several strategies. The first is to address the colors issue -- the web palette. By using the standard web palette, designers can try to match their background and text colors to colors that anyone with a 256 color graphics card/monitor can see. It's useless to try and do this for images, but the graphics card will dither that anyway. The second is by reducing the page weight and the number of files that need to be reloaded. That's one of the things that XHTML and CSS is about. The average page weight on a page full of data after I converted our corporate intranet to XHTML 1.0 Trans and linked stylesheets was 10k, down from approximately 60-70k using a table-and-graphic-based layout. By using stylesheets and commonly available fonts or alternatives, designers can come close to ensuring that their site will be visible the way that it is intended to look (including fonts) on the widest variety of computers that are likely to be in use to visit the website. It's very unlikely these days that someone will be surfing the web with a 16-color display. Text-only (lynx) is more likely, but modern standards take that into account and simply hide the stylesheet from those computers. If the designer is worth his salt, the website will still display fully. Unfortunately, it takes way too long to download a PDF with embedded images on a 28.8 modem out in West BFE. The CEO's cousin won't be happy, and neither will the CEO, which means the designer will lose his job. Which gets your theory nowhere.
18 point times new roman (Windows default for h1 text) really screws with your brochureware site if you don't style it to something more appropriate to your site. I guess I don't understand what you're saying - you imply that consistent look and feel is a drug that webmasters are on that they need to get off of; but also that consistent look and feel has failed because of webmasters?
Zeldman responded to a lot of the points brought up before in this MetaFilter Thread. (This story is about a week old.)
What Mr. Zeldman is promoting is forwards-compatibility. The traffic for 4.x browsers is finally receeding; most people (thanks to AOL or Windows upgrades) are on IE 5.x+. If you write your sites so that they're still readable in 4.x, even if they don't look good, that's good enough. (Explaining to PHB's that it would take three times the time it's already taken you to code for 4.x also helps, even if it's stretching it a bit.) What you need to look at is foward compatibility. It's like programming for APIs - you knew that the API calls for win95 weren't going to go away and break your code in 98. Well, the tag formats for XHTML-1.0Trans and CSS 1.0 won't break in the future. That's why we have standards.
Now if IE would just fix it's damned box model...
You are incorrect that the Sentra CA is the only SULEV vehicle on the road. Honda Accord EX-L's and all hybrids are registered as SULEV in California, and indeed, the air coming out of the tailpipe of an Accord EX-L is cleaner than the air going in the intake.
Ah, Bluethundr - All the information about in-jokes you just gave is also in the ST:TNG tech manual. I'm really curious to see if you've got pictures with closeups of these things -- I never quite belevied the manual!
Heh, watch /. crash the whole infrastructure by hitting the webcam all day...