If something is built for XP I wouldnt give two hot damns about it being able to work on XP. If its built for XP, make it work on 3.1. I dare ya.
You obviously have never tried to get an old program to compile on a newer platform (Unix/Linux). Here's an anecdote from me. There is a police station I know of that has a Sun 3 (yes, the 680x0 based one) running 24/7 because of exactly one program that will not compile nor run on anything more modern and it has no assembly code in it. It just uses old APIs.
Oh and just out of curiosity, when exactly are things "just working" in the windows world ? Is that the five minutes before or after all the updates, defragging, anti-virusing, anti-malwaring and constant reboots ? Cause if things are "just working" somebody might want to let all the symantecs of the world that the myriad of products they put out to fix microsofts constant fuckups are wholly un-needed.
You've also obviously never used Windows much. I don't run virus checkers, defraggers, or any of that stuff on my machines, but then again, I don't have them wide open exposed to the outside world either and I'm at least smart enough not to open any unsolicited attachment. My boxes "just work" just like my Linux servers and workstations "just work". As far as patches, my SuSE 9.2 boxes have about two patches per week, on average, and have had that since I installed it on two boxes about a week after the release.
Yeah, when this topic came up with the non-working model, I posted a link to the Intel pages where they showed something that looked similar to a Mac Mini.... in 1998. I'll post it again... Here it is
The other situation, which I've seen a few times lately, is that an untrained person reinvents the world because he's never heard of some of the basics. Like recently... a guy was all excited about "discovering" something and explained it to me. I said... "so... you almost mean a quad-tree, which you have if you use this one other optimization..." So, it only took the guy a month or so of thinking to get there, where we were about 12 years ago.
So just about anybody can be a programmer, and get payed only if his software will be usefull and people will use it. Wouldn't you like to live in that future?
Not really. I've seen plenty of code written by that "almost anyone who can be a programmer" person you speak of. 99 times out of 100 it is complete crap and I wish I had the time I spent dorking with their crap back.
There's no free ride anymore, it's time to innovate or die.
Depends on which side of the coin you are on. If you are on the consumer side, choose F/OSS and it can be a free ride. Unfortunately, shrink wrap software companies probably are going to have a hard time paying salaries of programmers so if you program, you'd better start liking jobs where all you do is tweek F/OSS for "customization" for your site.
So let's see you hire some high IQ people and start thinking up new ideas and industrial progress will be off and running again after a short stall!
And if you're a shrink wrap house, you'll pay these high IQ salaries with... what exactly? If you *do* come up with something great, you'll have 100 SourceForge copycats within a month and they will erode your market.
F/OSS is the great poison pill of software. If anyone comes out with something that is good (and it isn't you), then just put some effort into a F/OSS "alternative" and poison the whole market... basically make it where if *I* can't make any money in that market, then no one will.
Re:So, you programmers ready to give up your jobs?
on
McVoy Strikes Back
·
· Score: 1
Thanks for a reasonable response.
I agree with you on the breakdown of software. I haven't worked on a shrink-wrapped software bundle in, well, ever.
However, a lot of the "in-house programming" that I've seen has been "write us up some web pages" on the most simple end to a lot of "modify this so it can do this new special case that just came up" type work. Neither are really very high on the list of "programming" tasks and skillsets. On the other end, you get "we have to write all this stuff new to do these new things" where there is usually some challenge.
So, simply adapting F/OSS applications with some in-house tuning/tweeking is something typically that almost anyone can do and, in my opinion, isn't a job that I would care to have. I guess most VB haters would say is similar to monkeying around with VB (with the equivalent skillsets). I guess I've been lucky, though, that I've been able to get jobs writing substantial amounts of new code and/or significantly rearchitecting existing code.
Anyway... the detrimental part that I see is that F/OSS may drive programming into a commodity where the most common "programming" is simply tuning. Since programming will become commodity (even without F/OSS, the elevation of 3rd world countries will see to this), there will be fewer incentives to get formal training because of the cost/benefits of it.
Re:So, you programmers ready to give up your jobs?
on
McVoy Strikes Back
·
· Score: 1
Happy that you found out that you aren't alone in the world?
Re:So, you programmers ready to give up your jobs?
on
McVoy Strikes Back
·
· Score: 1
Hi back, reality just called looking for you as well. Obviously I chose a language that I thought was very unlikely to be used but was indicative of a type of language that anybody with access to a keyboard could learn, to illustrate a point. I'm sorry I didn't surround it by neon signs so that you'd get a better clue that I was making a statement by going overboard on it for emphasis.
Sometimes you gotta read the whole thing and ingest the entire message instead of focusing on one word to get the point.
The real limitation of the Cell processor would be context switches Why would this matter? The PPC core would handle the interrupts, and as I understand it, the SPUs would be treated like vector processors, which would be assigned a work unit and would process that till completion. Was something else said durring the presentation?
Well, on a context switch, the PPC has to save all its registers out for the next context to load. The fact that it has 128 VMX/Altivec registers (all pretty large) is a big load to push every context switch. Similarly, what are you going to do about the SPEs on a context switch? In a console, there are no/few context switches, especially not the general purpose OS kind to load another process. What do you do with the SPEs? Do you let them keep going doing their thing? In that case, one user can lock them all down and no one else can use them. The other side of the coin is that you have to swap them all out as well... so now your context switch has gone from ~64 64-bit registers and 32 VMX registers and a few other things... less than 1 KILOBYTE (and this is considered a lot in the realm of context switches)... to 8x256 KILOBYTES (2 MEGABYTES) just for the SPEs and the additional 64 VMX/Altivec registers are just noise in this. So, you want to context swap out 2 MByte every time the OS wants to run another task (60 times a second?) Can you say "slow"?
"Seventh. Forced uniformaty. If you put Linux on all the systems it will be only a mater of time untill someone who doesn't like Linux will bring there copy of XP from home and reinstall it on their system. And shortly after that the network is invaded with a virus again."
Yeah... and everyone at work should do the things the way the IT folks say they should do it rather than doing it how they think it should be done and IT supporting what needs to be done. I've had this discussion with IT folks (I *am* an IT folk) many times already. IT folks should be there to support the work that is being done. IT folks shouldn't be the ones declaring how work *should* be done.
Yeah, but the hardware is pretty expensive to justify when you can grab an x86 machine. For example, anyone can get a box from Dell for usually around $250 that will run Linux just fine (and is significantly faster than the Mac Mini). So, if given a Mac for some reason, I could understand putting Linux on it. However, if your goal is to run Linux, I, personally, couldn't justify buying a Mac to run it on (especially for the performance ranges I'm used to when running on x86 and x86-64 boxes).
One thing that I've always admired about Apple is that (like Google) they seem to have a corporate culture which heavily encourages new features to be integrated ELEGANTLY into existing frameworks. They really seem to spend time, thought, money, and even passion on finding a "clean" way to do things.
So... if this is as you say, what was all that stuff I heard recently about being able to install widgets or something onto the widget bar remotely through a web page without the user's consent.
From what I've seen, Apple has been just as guilty as anyone else (including Microsoft) as of late with their own home-brewed applications having security issues. I've even seen lots of complaints about how big the OS X security patches are (takes a long time to download and install or whatever).
A popular myth can be dispelled by annecdotal evidence. You've picked exactly ONE case out of potentially THOUSANDS to attempt to prove your point.
So what... Apache is good when compared to IIS. That means NOTHING when compared to... well... any other application or the state of the world in general.
Heh... I know sites with over 2000 Unix workstations and over 5000 Wintel boxes managed by less than 20 people... successfully.
Re:So, you programmers ready to give up your jobs?
on
McVoy Strikes Back
·
· Score: 1
Its actually worse that this....
IF everything goes OSS and everyone has to do it in their spare time, why is *anyone* going to get any formal training in CS or the like? It's definitely NOT cost effective to spend a couple $10K on a degree that will not pay itself back. So, you get fewer people getting formal CS training because there's no real job market there. Less formal CS training and you get more and more hacks (people who just chop and hack at something until it almost works) rather than supposed trained professionals. So, in the end, we get a bunch of people who like playing Nintendo who think computers are 'kewl' and learn to bang out something in BASIC and that's the software we'll have.
While I like getting F/OSS for free (as in beer) as the next guy, I think it will eventually cause harm.
Hello McFly... *every* console since, like, the Nintendo is a loss leader. They make their money back selling development kits and licenses. The money is in the games so they discount the hardware so that people will buy the platform then the games for it.
Good thinking by IBM. Basically, get a lot of labor for free to make their chip popular. All that labor will surely make them more money as they sell the hardware and make money off the free labor.
Yes, they are... Some of the early ones contained various chemicals such as methyl alcohol as well. I would *not* recommend anyone cutting open those things.
How I know this: Someone I know (wasn't me) decided for Halloween to cut some of those open and smear the glowy stuff on their face to make their face glow. Well, shortly after doing that, he became very ill and we took him to the emergency room where they told us not to do that anymore and why. I was there and witnessed this first-hand, this isn't an urban legend.
Not only is this last week old but it is hardly interesting. I can't tell you how many presentations I've given about Linux software that we've written using PowerPoint.
I've also emailed presentations that were written on Linux using OpenOffice and displayed on PowerPoint because someone forgot to bring the right laptop...
that entire thing is what apple sell, the whole package, together. a solution to problems encountered irl.
This sounds remarkably like Intel's new mantra ("It's a platform" thing), which is regarded as an excuse and a diversion from their getting their asses handed to them by AMD in performance right now.
The "solution" thing was really big in the 80s and early 90s. It didn't work. Companies sold proprietary software that ran on their proprietary hardware and it was their "solution". The problems were several:
a) It was typically very expensive because the company had to support both hardware and software groups b) It was "slow" in that companies who focused more on one thing (say, just the hardware or just the software) tended to do better jobs. The proprietary hardware makers couldn't keep up with the likes of Intel (and now AMD) in performance OR price.
Most of the companies that did this sort of thing have either folded completely or have transitioned over to software only or to making their hardware from commodity parts (read: Intel and AMD) or doing both (hardware from Intel/AMD and they do software). Examples: HP, Compaq, Intergraph, SGI, etc. The only holdouts left are Apple and Sun in the workstation/PersonalComputer world. Apple has been valiantly holding on, even having spruts of growth, but they are still considered a minor player by market percentages.
Technically, those PPCs that can flip endianness on the fly are actually native in either mode. Set the mode and until you change it back, the PPC *is* a little endian CPU (or big endian, depending on how you set it).
Data storage is an issue but not one that is that complicated. In fact, it's not that painful to do endian swaps on x86-64 processors, for example, because there's a dedicated instruction in the ISA to do it. If the binary data files have an identifier in them (version number, etc.) then the swap can be done on the fly pretty fast and easily. I worked on a product (back in the early 90s) that had to have all I/O (network, HDD, etc) able to handle endianness issues on the fly because our product ran on both big- and little-endian machines and all were expected to work together in any combinations (server side on either type independently of client side being either type). It's not that hard if your software is written reasonably well (all particular I/O handled in libraries inside your code instead of spread out all over Hell's 40 acres).
And I agree with you about XML being a pig... it uses a lot of CPU cycles but at least it's a memory hog, too/rolleyes
Slashdot Mirror
If something is built for XP I wouldnt give two hot damns about it being able to work on XP. If its built for XP, make it work on 3.1. I dare ya.
You obviously have never tried to get an old program to compile on a newer platform (Unix/Linux). Here's an anecdote from me. There is a police station I know of that has a Sun 3 (yes, the 680x0 based one) running 24/7 because of exactly one program that will not compile nor run on anything more modern and it has no assembly code in it. It just uses old APIs.
Oh and just out of curiosity, when exactly are things "just working" in the windows world ? Is that the five minutes before or after all the updates, defragging, anti-virusing, anti-malwaring and constant reboots ? Cause if things are "just working" somebody might want to let all the symantecs of the world that the myriad of products they put out to fix microsofts constant fuckups are wholly un-needed.
You've also obviously never used Windows much. I don't run virus checkers, defraggers, or any of that stuff on my machines, but then again, I don't have them wide open exposed to the outside world either and I'm at least smart enough not to open any unsolicited attachment. My boxes "just work" just like my Linux servers and workstations "just work". As far as patches, my SuSE 9.2 boxes have about two patches per week, on average, and have had that since I installed it on two boxes about a week after the release.
Anecdotes are a lot of fun.
Yeah, when this topic came up with the non-working model, I posted a link to the Intel pages where they showed something that looked similar to a Mac Mini.... in 1998. I'll post it again... Here it is
The other situation, which I've seen a few times lately, is that an untrained person reinvents the world because he's never heard of some of the basics. Like recently... a guy was all excited about "discovering" something and explained it to me. I said... "so... you almost mean a quad-tree, which you have if you use this one other optimization..." So, it only took the guy a month or so of thinking to get there, where we were about 12 years ago.
How does anyone presume to tell people how to think?
Fixed that for you.
However, this person is just stating an opinion... and... opinions are like assholes... everybody has one.
So just about anybody can be a programmer, and get payed only if his software will be usefull and people will use it. Wouldn't you like to live in that future?
Not really. I've seen plenty of code written by that "almost anyone who can be a programmer" person you speak of. 99 times out of 100 it is complete crap and I wish I had the time I spent dorking with their crap back.
There's no free ride anymore, it's time to innovate or die.
Depends on which side of the coin you are on. If you are on the consumer side, choose F/OSS and it can be a free ride. Unfortunately, shrink wrap software companies probably are going to have a hard time paying salaries of programmers so if you program, you'd better start liking jobs where all you do is tweek F/OSS for "customization" for your site.
So let's see you hire some high IQ people and start thinking up new ideas and industrial progress will be off and running again after a short stall!
And if you're a shrink wrap house, you'll pay these high IQ salaries with... what exactly? If you *do* come up with something great, you'll have 100 SourceForge copycats within a month and they will erode your market.
F/OSS is the great poison pill of software. If anyone comes out with something that is good (and it isn't you), then just put some effort into a F/OSS "alternative" and poison the whole market... basically make it where if *I* can't make any money in that market, then no one will.
Thanks for a reasonable response.
I agree with you on the breakdown of software. I haven't worked on a shrink-wrapped software bundle in, well, ever.
However, a lot of the "in-house programming" that I've seen has been "write us up some web pages" on the most simple end to a lot of "modify this so it can do this new special case that just came up" type work. Neither are really very high on the list of "programming" tasks and skillsets. On the other end, you get "we have to write all this stuff new to do these new things" where there is usually some challenge.
So, simply adapting F/OSS applications with some in-house tuning/tweeking is something typically that almost anyone can do and, in my opinion, isn't a job that I would care to have. I guess most VB haters would say is similar to monkeying around with VB (with the equivalent skillsets). I guess I've been lucky, though, that I've been able to get jobs writing substantial amounts of new code and/or significantly rearchitecting existing code.
Anyway... the detrimental part that I see is that F/OSS may drive programming into a commodity where the most common "programming" is simply tuning. Since programming will become commodity (even without F/OSS, the elevation of 3rd world countries will see to this), there will be fewer incentives to get formal training because of the cost/benefits of it.
Happy that you found out that you aren't alone in the world?
Hi back, reality just called looking for you as well. Obviously I chose a language that I thought was very unlikely to be used but was indicative of a type of language that anybody with access to a keyboard could learn, to illustrate a point. I'm sorry I didn't surround it by neon signs so that you'd get a better clue that I was making a statement by going overboard on it for emphasis.
Sometimes you gotta read the whole thing and ingest the entire message instead of focusing on one word to get the point.
The real limitation of the Cell processor would be context switches
Why would this matter? The PPC core would handle the interrupts, and as I understand it, the SPUs would be treated like vector processors, which would be assigned a work unit and would process that till completion. Was something else said durring the presentation?
Well, on a context switch, the PPC has to save all its registers out for the next context to load. The fact that it has 128 VMX/Altivec registers (all pretty large) is a big load to push every context switch. Similarly, what are you going to do about the SPEs on a context switch? In a console, there are no/few context switches, especially not the general purpose OS kind to load another process. What do you do with the SPEs? Do you let them keep going doing their thing? In that case, one user can lock them all down and no one else can use them. The other side of the coin is that you have to swap them all out as well... so now your context switch has gone from ~64 64-bit registers and 32 VMX registers and a few other things... less than 1 KILOBYTE (and this is considered a lot in the realm of context switches)... to 8x256 KILOBYTES (2 MEGABYTES) just for the SPEs and the additional 64 VMX/Altivec registers are just noise in this. So, you want to context swap out 2 MByte every time the OS wants to run another task (60 times a second?) Can you say "slow"?
It is a university.
"Seventh. Forced uniformaty. If you put Linux on all the systems it will be only a mater of time untill someone who doesn't like Linux will bring there copy of XP from home and reinstall it on their system. And shortly after that the network is invaded with a virus again."
Yeah... and everyone at work should do the things the way the IT folks say they should do it rather than doing it how they think it should be done and IT supporting what needs to be done. I've had this discussion with IT folks (I *am* an IT folk) many times already. IT folks should be there to support the work that is being done. IT folks shouldn't be the ones declaring how work *should* be done.
Yeah, but the hardware is pretty expensive to justify when you can grab an x86 machine. For example, anyone can get a box from Dell for usually around $250 that will run Linux just fine (and is significantly faster than the Mac Mini). So, if given a Mac for some reason, I could understand putting Linux on it. However, if your goal is to run Linux, I, personally, couldn't justify buying a Mac to run it on (especially for the performance ranges I'm used to when running on x86 and x86-64 boxes).
One thing that I've always admired about Apple is that (like Google) they seem to have a corporate culture which heavily encourages new features to be integrated ELEGANTLY into existing frameworks. They really seem to spend time, thought, money, and even passion on finding a "clean" way to do things.
So... if this is as you say, what was all that stuff I heard recently about being able to install widgets or something onto the widget bar remotely through a web page without the user's consent.
From what I've seen, Apple has been just as guilty as anyone else (including Microsoft) as of late with their own home-brewed applications having security issues. I've even seen lots of complaints about how big the OS X security patches are (takes a long time to download and install or whatever).
A popular myth can be dispelled by annecdotal evidence. You've picked exactly ONE case out of potentially THOUSANDS to attempt to prove your point.
So what... Apache is good when compared to IIS. That means NOTHING when compared to... well... any other application or the state of the world in general.
Heh... I know sites with over 2000 Unix workstations and over 5000 Wintel boxes managed by less than 20 people... successfully.
Its actually worse that this....
IF everything goes OSS and everyone has to do it in their spare time, why is *anyone* going to get any formal training in CS or the like? It's definitely NOT cost effective to spend a couple $10K on a degree that will not pay itself back. So, you get fewer people getting formal CS training because there's no real job market there. Less formal CS training and you get more and more hacks (people who just chop and hack at something until it almost works) rather than supposed trained professionals. So, in the end, we get a bunch of people who like playing Nintendo who think computers are 'kewl' and learn to bang out something in BASIC and that's the software we'll have.
While I like getting F/OSS for free (as in beer) as the next guy, I think it will eventually cause harm.
Hello McFly... *every* console since, like, the Nintendo is a loss leader. They make their money back selling development kits and licenses. The money is in the games so they discount the hardware so that people will buy the platform then the games for it.
It's not rocket science.
Just because you think I'm a troll doesn't mean that I am wrong. In fact, I would welcome someone to prove me wrong.
Or does "troll" simply mean that even though it's true, you refuse to admit it?
Good thinking by IBM. Basically, get a lot of labor for free to make their chip popular. All that labor will surely make them more money as they sell the hardware and make money off the free labor.
Yes, they are... Some of the early ones contained various chemicals such as methyl alcohol as well. I would *not* recommend anyone cutting open those things.
How I know this: Someone I know (wasn't me) decided for Halloween to cut some of those open and smear the glowy stuff on their face to make their face glow. Well, shortly after doing that, he became very ill and we took him to the emergency room where they told us not to do that anymore and why. I was there and witnessed this first-hand, this isn't an urban legend.
Not only is this last week old but it is hardly interesting. I can't tell you how many presentations I've given about Linux software that we've written using PowerPoint.
I've also emailed presentations that were written on Linux using OpenOffice and displayed on PowerPoint because someone forgot to bring the right laptop...
Yawn...
that entire thing is what apple sell, the whole package, together. a solution to problems encountered irl.
This sounds remarkably like Intel's new mantra ("It's a platform" thing), which is regarded as an excuse and a diversion from their getting their asses handed to them by AMD in performance right now.
The "solution" thing was really big in the 80s and early 90s. It didn't work. Companies sold proprietary software that ran on their proprietary hardware and it was their "solution". The problems were several:
a) It was typically very expensive because the company had to support both hardware and software groups
b) It was "slow" in that companies who focused more on one thing (say, just the hardware or just the software) tended to do better jobs. The proprietary hardware makers couldn't keep up with the likes of Intel (and now AMD) in performance OR price.
Most of the companies that did this sort of thing have either folded completely or have transitioned over to software only or to making their hardware from commodity parts (read: Intel and AMD) or doing both (hardware from Intel/AMD and they do software). Examples: HP, Compaq, Intergraph, SGI, etc. The only holdouts left are Apple and Sun in the workstation/PersonalComputer world. Apple has been valiantly holding on, even having spruts of growth, but they are still considered a minor player by market percentages.
Mmmm... salt and vinegar chips... I *love* those. The problem is that they are typically hard to find at sandwich shops :(
Technically, those PPCs that can flip endianness on the fly are actually native in either mode. Set the mode and until you change it back, the PPC *is* a little endian CPU (or big endian, depending on how you set it).
/rolleyes
Data storage is an issue but not one that is that complicated. In fact, it's not that painful to do endian swaps on x86-64 processors, for example, because there's a dedicated instruction in the ISA to do it. If the binary data files have an identifier in them (version number, etc.) then the swap can be done on the fly pretty fast and easily. I worked on a product (back in the early 90s) that had to have all I/O (network, HDD, etc) able to handle endianness issues on the fly because our product ran on both big- and little-endian machines and all were expected to work together in any combinations (server side on either type independently of client side being either type). It's not that hard if your software is written reasonably well (all particular I/O handled in libraries inside your code instead of spread out all over Hell's 40 acres).
And I agree with you about XML being a pig... it uses a lot of CPU cycles but at least it's a memory hog, too