I thought scientific enquiry required having an open mind. There are many phenomena we don't understand - and many we will never understand in our lifetime. Unless I was able to examine the device myself, I wouldn't make a comment regarding whether it works or not, and whether it represents a fundamental example of some new property in the physical world or not.
If every scientist and inventor in history were to follow your lead, the Earth would still be flat, and the Sun and planets would still circle the Earth and we would be walking everywhere - because previous 'great geniuses' said so.
Let's hope the Telco's equipment also works underwater - or is at least water-proof.
The latest pedistals are basically a sealed heavy-duty fibreglass shell that fits over the top of the terminals that are positioned near the top of the shell - secured at the bottom. So the terminals and ends of the underground cables should remain relatively dry in flooding conditions.
Windows 2000 - from the guys who brought us edlin
You probably already know this, but for the benefit of those not in the know: edlin duplicates a subset of the functionality of the 'ed' line editor that is the underlying editor for the 'vi' page-editor. ed was written by Ken Thompson for Unix in fact - a long time before edlin came along. 'ed' is still available on all Unix and Linux systems. edlin, while still available on some of the latest versions of Windows, is of limited usefulness since it can not handle long file names. I do have a soft spot in my heart for edlin though - it was the first editor I used under DOS - before I acquired WordStar and later WordPerfect.
Of course, now I use emacs and OO - a good mixture of timeless and the new.
Wikipedia links on ed and edlin for software archaeologists.
Put the scroll lock with the 'prtscrn' 'scrlk' and 'pause/break' keys, and free up that space for an additional meta shifting key...a la Space Cadet Keyboard.
Think of all the possible key combinations you can attain using CTRL-ALT-META-SHIFT - it boggles the mind. Not to mention, emacs users will have an actual 'Meta' key to use on PCs (instead of the 'ESC' key).
People don't seem to realize that neighbors might want to work at home, and don't want to be distracted with, e.g. loud music of any sort...
Actually, if the developers didn't cram us together like sardines on ever shrinking plots so they can 'maximize' their investments (while minimizing quality of life) this wouldn't be an issue.
It is almost too expensive for you to own a piece of land larger than 1/8 of an acre in the suburbs anymore. And you can have the 'upper middle-class' side of town, where everyone crams 4000 sq ft. houses on 1/4 acre plots - close enough together to touch with arms outstretched. It is disconcerting to step out on your patio and look up to see the neighbor staring at you through his kitchen window.
Studies have been done with rats where the lack of space lead to competition for limited resources (sleeping platforms), violence, and psychotic problems in the animals.
My next place is going to be in a low property tax rural area - so I can get the seperation necessary to keep my mental health intact - thank you.
Unless you get a 64 bit processor: using a 64-bit value for time_t introduces a new wrap around date in about 290 billion years, on Sunday, December 4, 292,277,026,596 15:30:08 UTC.
As of 2005 BSD uses 64 bit time_t on 64 bit processors.
As of 1995 Linux on Sparc64 and Alpha64 systems used a 64 bit time_t.
It is not clear (at least I wasn't able to google for it) if x86 linux's time_t is 64 bit compliant.
I found that there's no requirement to use an integer type for time_t at all. People could already be using a 64-bit time_t on a 32-bit platform if they wanted:
typedef struct{
char block[8]; } time_t;
Or even typedef double time_t;
In all places where time_t is used or defined (libc and the kernel) this would fix it on 32 bit systems. That being said, using a more complex structure will add microseconds to every time calculation - which might manifest as slower response for these calculations on a 32 bit box.
Of course, by 2038 a 32 bit box is not going to be like a we view an 8086 today - a dinosaur, albeit useful for some limited applications. We might also see these processors in embedded systems (like your refrigerator, car, power tools, toaster etc...) - in which case it may only be a problem if the device needs to be able to do time representation/calculations; again, the fix is indicated above (I would guess embedded devices have quite a bit more free cpu cycles compared to their workstation cousins --- think about it, we have 8088 and 286 processors running in cars today --- beyond the year 2000 without issues...it is all relative to how you build the system that will run on the chip and its overall purpose).
I am not worried about this issue. We will solve it one way, or another.
'Tis better to be silent and be thought a fool, than to speak and remove all doubt.
I am rather inclined to silence, and whether that be wise or not, it is at least more unusual nowadays to find a man who can hold his tongue than to find one who cannot.
My point was I already have a system that works well - why would I want to move to a new Windows paradigm that doesn't buy me any significant improvement over what I have already?
Many times what MS trotts out as 'gee-whiz-new', is already available in Unix/Linux/BSD in one form or another, usually in a more stable and easier to use implimentation that interoperates better with existing systems of various flavors.
The problem is not cell phone use in and of itself causing crashes. That is just a symptom of a bigger problem: people are not trained to use cell phones properly while driving and usually don't have the correct equipment to do so.
When I was in the military I drove tracked vehicles while communicating on a radio net, and also talking on an internal intercom system with a TC and squad leader. Getting in an accident would have been far more catastrophic given the weight and size of the equipment I was operating.
Similarly, Pilots also have to communicate while controlling an expensive piece of equipment - and I've also done that.
In both cases I never had an accident. I can't imagine the military or aviation systems working without radio communications. Similarly the efficiency of using the Cell phone has provided amazing and equally important impacts to the civilian world.
The number one key is to have the right equipment for 'hands free' operation. For cell phones this means buying and using the voice-dial features available on most phones now, and getting a headset for hands free operation in your vehicle.
Secondly you must learn to modify your driving habits so that if the conversation moves to a point of needing to take your eyes off the road (e.g. to search for or record information), that you then pull off the road and carry on the conversation without impacting your driving ability. You should never manually dial a number into your phone while driving, and never attempt to write something down, or search for some item in your briefcase or purse, for that matter.
Banning the use of Cellphones in cars is not the solution; proper training and equipment is the right answer.
No, Mac users are just blessed with greater creativity.
I call BS on that. If I recognize a problem with the hardware that is too expensive to get repaired through normal channels (or there is no 'fix' because it was designed that way), I might think about engineering a solution. That solution, however, will not entail toothpicks, duct-tape, or paper origami cranes. In this example, depending on the heat characteristics of the area in question, I would make a appropriately sized element out of styrene (plastic) or sheet metal - and affix it to the device permanently. While I don't know the details of what was required from an engineering standpoint (there might be another way to fix it that is more efficient or less intrusive) - I do know that my approach would be from a standpoint of engineering a proper solution - NOT jerry-rigging a sloppy, and potentially dangerous half-way 'solution'.
I think doing it the right way is far more creative to the alternative. Jerry-rigging may work for a short time, but is not a permanent solution, and is a lesser form of creativity IMHO.
As an example, its like the difference between the guy with the brand new Corvette, who used wire coat-hangers to hold on his muffler, and the guy who bought an old '57 Chevy and restored it to near-stock condition. Who is more creative? The Corvette owner grabbed some coathangers and crawled under his car. The Chevy owner restored the engine, perhaps to the extent of fabricating parts, did body work, restored interior components, painted the exterior and upholstered the interior. I think it is obvious.
Some people know the cost of everything, and the value of nothing. (Can't recall who I am paraphrasing, but I think it applies here)
your libraries load up as seperate processes, and use pipes to communicate with each other
This sounds alot like Unix/Linux to me - in fact Unix had interprocess communication in 1970 - before Microsoft existed. If they just implimented a proper Posix compliant OS back in the day, instead of fighting it at every turn (or trying to extend, embrace and crush it) , they would have gained - of course, who would pay their exhorbitant prices now for something that is already available for free - to a large extent because of the industry's refusal to make that technology available on a wider basis?
There are WYSIWYG xml editors out there - so you don't have to delve down into the ugly details unless you really want to -- and you can modify the online look via CSS, and use other filters to generate PDF, and other formats as needed.
It is not rocket science.
Kupu, an open source WYSIWYG XHTML editor that you can run from your web browser can be found here: http://kupu.oscom.org/
That is certainly possible, but I would not bet on it. Microsoft will only do what they believe is in the best interests of their business. If they can not control access via their branded products, then they do not want to bother with it. Time and time again they have attempted to extend and destroy standards (remember J++?) for their own ends. They are still trying to milk the old cash cows that are slowly drying up by keeping us all on the Microsoft desktop, and using Microsoft Office products.
This is not in the best interests of interoperability - which in turn is not in the best interests of the network, or the consumer.
Most of the problems you mention would be addressed by simply using standards, instead of trying to think up your own way of doing things (e.g. to 'lock-in' customers).
Posix is an excellent interface standard. Various W3C standards are excellent choices for web development.
OS developers can make their systems properly interoperate - but they choose not to. Rather than pointing a finger at software developers - perhaps these large companies that do nefarious things to bypass existing standards for their own ends should be held to account for their negative impact on application stability.
Whereas in software, the requirements absolutely change (often by orders of magnitude) over time...It was always frustrating that the system I was developing had no requirements document and once it was written it changed every day.
You say that like it is a bad thing. Change is the reality whenever you are talking about building systems for human beings - who CAN NOT KNOW EVERYTHING about their needs and uses of a system before they get their hands on it (unless it is a VERY simple system - and even if it is a simple system that is no guarantee, you can not make assumptions that requirements won't change).
Knowing that simple fact, you would think software development paradigms would have evolved to take that into account. In fact, software development paradigms have evolved, but their use remains on the fringes. This is the prime reason the number one risk involved in software development projects is the 'use of an inappropriate methodology'. In large part development shops use what they are familiar with - and usually what they are familiar with - or more importantly, the lead software architect who last studied software development paradigms in 1974 is familiar with - is a strict waterfall development lifecycle paradigm that involves all specifications defined up front and creation of some monolithic ugly to modify system. Most projects should be modeled after iterative 'agile' models that produce more stable and modular applications THAT ARE DESIGNED TO BE MODIFIED.
I've been a developer, project manager and advisor on multiple million dollar projects - and the ones that have had cost overruns and have failed to meet the needs of the end users all had the same characteristic: they all chose to use a waterfall method which was inappropriate for dynamic systems.
We are living in the 21st century - get with the program and leave your old 20th century development paradigms behind. Learn your craft, and push for changes. I have had success implimenting iterative development lifecycle projects - and these projects have been under budget and on time every time - outperforming traditional models. It is an uphill battle because the 'old heads' want to keep their turf (the legions of programmers they have acquired over the intervening years) - and usually have the ear of their buddies at the top. But everyone retires, and with them will go their inefficient and ineffective design philosophies. Sadly, we will continue to flush money down the toilet with every boondoggle that comes along until they are gone.
Most MMO games (including large scale FPSs - such as WWIIonline/Battlefield Europe) evolve, and I would argue that is the future for multiplayer games of all types.
As new content is developed or old content is revamped, it is added to the mix on a continuous basis.
In fact, for open source games a pay-to-play model would probably work better than attempting to make a living on shrink-wrapped one-offs.
Actually, it could be argued that the idea of 'shrink-wrapped' software in general is on the way out as the new business models shake out. However, the profit margins will be much less than they are today because people aren't going to pay $50 to download a game, but they will pay $5 on a recurring basis for an MMO game (that in 10 months will make your original projection of $50 - and then some in the months and years that follow).
Thank you for that wonderful strawman (that both pollutes your beverages and eats your offspring). Your fallacy is making the assumption that the free 'dog' is of a lower quality than the nonfree dog.
A more accurate metaphor is someone has given you a free Rolex watch that keeps time accurate to.0001 seconds over the course of a year. Meanwhile, the vendor on the streetcorner is trying to convince you to buy a used Swatch that is far less accurate, and who's face shows numbers in Mandarin Chinese for $2000 by arguing the Rolex takes longer to put on in the morning.
The idea with XML is to have a portable format that can be used by various applications/services (web, editors, and XML backend parsers).
The power with XML is that not only does it describe a document - but that it can also be parsed by search engines and meta data can be embedded which all taken together - allow your documentation to also serve as a data source for various applications - (tied to RSS feed perhaps, part of taxonomy based search engine etc..) some of which are only now being developed - and many that are just ideas.
Embedding a proprietary binary format into XML defeats the purpose of this and is, in fact, not 'open' at all.
More FUD from Redmond - why is anyone surprised by this?
We are just begining to see the tip of the iceberg - in the form of open source and free applications (google, firefox, openoffice, linux etc...)
Over the next 10 years you are going to see more and more buy-in of the alternatives, so much so that it will marginalize the shrink-wrapped software industry unless they change. That change will be painful to them - and may not be possible for some, because it will mean much smaller development teams that generate less overall revenue than before. Good for quality developers, bad for borderline 'wanabe' developers.
One passage in the article was telling:
Example: Item 10016. Linux and MacOS users have problems over how end-of-line terminators show up. Last October, we tried to fix this and accidentally introduced a nastier bug that prevented users creating new versions of a project.
This tells me that the application code is too closely coupled (monolithic code) - which unnecessarily increases complexity. The module that displays (presumably) a stream of characters should have nothing to do with the module that allows you to create a project (again making some presumptions about how such an interface would work - perhaps entering the name of the project, generating database entries or files etc...)
Instead of asking 'why don't we ship shrinkwrapped apps that are not bug free', I think we should be asking this larger question:
Why do we ship shrinkwrapped applications at all?
The model we are using is all wrong. Instead, we should be gearing our application lifecyle to handle iterative (recursive) development - releasing early and often via the network. Many pay-to-play games successfully use just such a model, updating content and patching bugs via uploads.
Add to that an agile process approach coupled with a design philosophy that emphasizes simple modules (that can be tested more completely, encorporating clearly defined APIs that don't allow undefined results to occur when external modules attempt to pass bad data) and you have a winner!
Thankfully, there are few developers who understand this concept - their continued delivery of faulty applications, that then takes more money to 'correct' (e.g. you buy the next version - which in fact has its own faults) makes me look like a CS god in comparison - and keeps me in business in areas where there is little tolerance for buggy code.
Anyway, I hope another new language comes along that'll blow away Ruby and another new web framework comes out that'll blow away RoR
...
Zope3 is cooking right along. Python blows away Ruby imho - the true measure is how productive it allows you to be. I've been a longtime developer of Perl, C and Java apps - but find Python is better for me mainly due to the ease of use and ease of debugging not possible with other alternatives.
Back in the 'good-ol' days - when you bought a piece of hardware (computer, radio, etc) included in the box was a schematics to the whole system. You could repair your own machine using the schematics if you wanted.
When did we stop doing this, and why? Are we more stupid now, than we were 30 years ago?
I agree with the parent. There is no Linux distribution that I can point to that is suitable for 'Joe User' - yet.
Before you think I am another M$ appologist -- I am a longtime Unix/Linux system administrator and developer, and have multiple machines running linux - and experience using many distributions. I am comfortable with Linux. In fact I made an effort to go 'window-less' on my home network. For my development work and keeping up on things at home, surfing the web and reading email - Linux is perfect.
The problem came when I attempted to get my large collection of MS Windows based video games working under linux. I tried Winex - which worked for some older games, but not for the newest games. I bought a subscription to Cedega and had no better luck. My particular distribution's libraries did not fully match the kernel that was running on my system, so I rebuilt the kernel to match (to get my video graphics card driver to load) - which then broke other libraries links. Cedega's dependencies were not well documented - and I would find them as I tried to get the games working.
To make a long story short, I spent months toying with it - but never got to do what I wanted to do - play my games without a hassle. So my game/media machine is now a windoze box once again; I don't have time to mess with it and accomplish the other things I want to in my short life.
I am lucky though - I have multiple machines, so if my game box decides to go down - I can get the other things done (email, web access, development) on my other machines. 'Joe User' usually doesn't have that option. His one machine has to do everything - and he definitely doesn't have time to tinker with it.
The solution as I see it is someone needs to build a Linux distribution that is geared towards Joe User 100%. He will want to play the cutting edge video games (built primarily for Windows machines) - an improved version of WINE or Cedega must be integrated with it. Libraries have to be clearly managed to avoid incompatibilities - and the user should not have to toy with it. In short everthing should 'just work' out of the box (printer setup, .
Failing that - and if you absolutely can not have Windows on your network - I would say save your pennies and spring for a MAC.
Slashdot Mirror
I thought scientific enquiry required having an open mind. There are many phenomena we don't understand - and many we will never understand in our lifetime. Unless I was able to examine the device myself, I wouldn't make a comment regarding whether it works or not, and whether it represents a fundamental example of some new property in the physical world or not.
If every scientist and inventor in history were to follow your lead, the Earth would still be flat, and the Sun and planets would still circle the Earth and we would be walking everywhere - because previous 'great geniuses' said so.
The latest pedistals are basically a sealed heavy-duty fibreglass shell that fits over the top of the terminals that are positioned near the top of the shell - secured at the bottom. So the terminals and ends of the underground cables should remain relatively dry in flooding conditions.
You probably already know this, but for the benefit of those not in the know: edlin duplicates a subset of the functionality of the 'ed' line editor that is the underlying editor for the 'vi' page-editor. ed was written by Ken Thompson for Unix in fact - a long time before edlin came along. 'ed' is still available on all Unix and Linux systems. edlin, while still available on some of the latest versions of Windows, is of limited usefulness since it can not handle long file names. I do have a soft spot in my heart for edlin though - it was the first editor I used under DOS - before I acquired WordStar and later WordPerfect.
Of course, now I use emacs and OO - a good mixture of timeless and the new.
Wikipedia links on ed and edlin for software archaeologists.
Put the scroll lock with the 'prtscrn' 'scrlk' and 'pause/break' keys, and free up that space for an additional meta shifting key...a la Space Cadet Keyboard.
Think of all the possible key combinations you can attain using CTRL-ALT-META-SHIFT - it boggles the mind. Not to mention, emacs users will have an actual 'Meta' key to use on PCs (instead of the 'ESC' key).
Actually, if the developers didn't cram us together like sardines on ever shrinking plots so they can 'maximize' their investments (while minimizing quality of life) this wouldn't be an issue.
It is almost too expensive for you to own a piece of land larger than 1/8 of an acre in the suburbs anymore. And you can have the 'upper middle-class' side of town, where everyone crams 4000 sq ft. houses on 1/4 acre plots - close enough together to touch with arms outstretched. It is disconcerting to step out on your patio and look up to see the neighbor staring at you through his kitchen window.
Studies have been done with rats where the lack of space lead to competition for limited resources (sleeping platforms), violence, and psychotic problems in the animals.
My next place is going to be in a low property tax rural area - so I can get the seperation necessary to keep my mental health intact - thank you.
Now - get off my lawn!
Unless you get a 64 bit processor: using a 64-bit value for time_t introduces a new wrap around date in about 290 billion years, on Sunday, December 4, 292,277,026,596 15:30:08 UTC.
As of 2005 BSD uses 64 bit time_t on 64 bit processors.
As of 1995 Linux on Sparc64 and Alpha64 systems used a 64 bit time_t.
It is not clear (at least I wasn't able to google for it) if x86 linux's time_t is 64 bit compliant.
I found that there's no requirement to use an integer type for time_t at all. People could already be using a 64-bit time_t on a 32-bit platform if they wanted:
typedef struct{
char block[8];
} time_t;
Or even
typedef double time_t;
In all places where time_t is used or defined (libc and the kernel) this would fix it on 32 bit systems. That being said, using a more complex structure will add microseconds to every time calculation - which might manifest as slower response for these calculations on a 32 bit box.
Of course, by 2038 a 32 bit box is not going to be like a we view an 8086 today - a dinosaur, albeit useful for some limited applications. We might also see these processors in embedded systems (like your refrigerator, car, power tools, toaster etc...) - in which case it may only be a problem if the device needs to be able to do time representation/calculations; again, the fix is indicated above (I would guess embedded devices have quite a bit more free cpu cycles compared to their workstation cousins --- think about it, we have 8088 and 286 processors running in cars today --- beyond the year 2000 without issues...it is all relative to how you build the system that will run on the chip and its overall purpose).
I am not worried about this issue. We will solve it one way, or another.
I think it has more to do with meeting in the teacher's lounge.
The fact is proximity provides opportunity for these relationships to flourish - regardless of what line of work you are in.
My point was I already have a system that works well - why would I want to move to a new Windows paradigm that doesn't buy me any significant improvement over what I have already?
Many times what MS trotts out as 'gee-whiz-new', is already available in Unix/Linux/BSD in one form or another, usually in a more stable and easier to use implimentation that interoperates better with existing systems of various flavors.
The problem is not cell phone use in and of itself causing crashes. That is just a symptom of a bigger problem: people are not trained to use cell phones properly while driving and usually don't have the correct equipment to do so.
When I was in the military I drove tracked vehicles while communicating on a radio net, and also talking on an internal intercom system with a TC and squad leader. Getting in an accident would have been far more catastrophic given the weight and size of the equipment I was operating.
Similarly, Pilots also have to communicate while controlling an expensive piece of equipment - and I've also done that.
In both cases I never had an accident. I can't imagine the military or aviation systems working without radio communications. Similarly the efficiency of using the Cell phone has provided amazing and equally important impacts to the civilian world.
The number one key is to have the right equipment for 'hands free' operation. For cell phones this means buying and using the voice-dial features available on most phones now, and getting a headset for hands free operation in your vehicle.
Secondly you must learn to modify your driving habits so that if the conversation moves to a point of needing to take your eyes off the road (e.g. to search for or record information), that you then pull off the road and carry on the conversation without impacting your driving ability. You should never manually dial a number into your phone while driving, and never attempt to write something down, or search for some item in your briefcase or purse, for that matter.
Banning the use of Cellphones in cars is not the solution; proper training and equipment is the right answer.
I call BS on that. If I recognize a problem with the hardware that is too expensive to get repaired through normal channels (or there is no 'fix' because it was designed that way), I might think about engineering a solution. That solution, however, will not entail toothpicks, duct-tape, or paper origami cranes. In this example, depending on the heat characteristics of the area in question, I would make a appropriately sized element out of styrene (plastic) or sheet metal - and affix it to the device permanently. While I don't know the details of what was required from an engineering standpoint (there might be another way to fix it that is more efficient or less intrusive) - I do know that my approach would be from a standpoint of engineering a proper solution - NOT jerry-rigging a sloppy, and potentially dangerous half-way 'solution'.
I think doing it the right way is far more creative to the alternative. Jerry-rigging may work for a short time, but is not a permanent solution, and is a lesser form of creativity IMHO.
As an example, its like the difference between the guy with the brand new Corvette, who used wire coat-hangers to hold on his muffler, and the guy who bought an old '57 Chevy and restored it to near-stock condition. Who is more creative? The Corvette owner grabbed some coathangers and crawled under his car. The Chevy owner restored the engine, perhaps to the extent of fabricating parts, did body work, restored interior components, painted the exterior and upholstered the interior. I think it is obvious.
Some people know the cost of everything, and the value of nothing. (Can't recall who I am paraphrasing, but I think it applies here)
This sounds alot like Unix/Linux to me - in fact Unix had interprocess communication in 1970 - before Microsoft existed. If they just implimented a proper Posix compliant OS back in the day, instead of fighting it at every turn (or trying to extend, embrace and crush it) , they would have gained - of course, who would pay their exhorbitant prices now for something that is already available for free - to a large extent because of the industry's refusal to make that technology available on a wider basis?
Day late and a dollar short...
Spain outlaws the internet. Pictures at 10...
There are WYSIWYG xml editors out there - so you don't have to delve down into the ugly details unless you really want to -- and you can modify the online look via CSS, and use other filters to generate PDF, and other formats as needed.
It is not rocket science.
Kupu, an open source WYSIWYG XHTML editor that you can run from your web browser can be found here: http://kupu.oscom.org/
That is certainly possible, but I would not bet on it. Microsoft will only do what they believe is in the best interests of their business. If they can not control access via their branded products, then they do not want to bother with it. Time and time again they have attempted to extend and destroy standards (remember J++?) for their own ends. They are still trying to milk the old cash cows that are slowly drying up by keeping us all on the Microsoft desktop, and using Microsoft Office products.
This is not in the best interests of interoperability - which in turn is not in the best interests of the network, or the consumer.
Most of the problems you mention would be addressed by simply using standards, instead of trying to think up your own way of doing things (e.g. to 'lock-in' customers).
Posix is an excellent interface standard. Various W3C standards are excellent choices for web development.
OS developers can make their systems properly interoperate - but they choose not to. Rather than pointing a finger at software developers - perhaps these large companies that do nefarious things to bypass existing standards for their own ends should be held to account for their negative impact on application stability.
You say that like it is a bad thing. Change is the reality whenever you are talking about building systems for human beings - who CAN NOT KNOW EVERYTHING about their needs and uses of a system before they get their hands on it (unless it is a VERY simple system - and even if it is a simple system that is no guarantee, you can not make assumptions that requirements won't change).
Knowing that simple fact, you would think software development paradigms would have evolved to take that into account. In fact, software development paradigms have evolved, but their use remains on the fringes. This is the prime reason the number one risk involved in software development projects is the 'use of an inappropriate methodology'. In large part development shops use what they are familiar with - and usually what they are familiar with - or more importantly, the lead software architect who last studied software development paradigms in 1974 is familiar with - is a strict waterfall development lifecycle paradigm that involves all specifications defined up front and creation of some monolithic ugly to modify system. Most projects should be modeled after iterative 'agile' models that produce more stable and modular applications THAT ARE DESIGNED TO BE MODIFIED.
I've been a developer, project manager and advisor on multiple million dollar projects - and the ones that have had cost overruns and have failed to meet the needs of the end users all had the same characteristic: they all chose to use a waterfall method which was inappropriate for dynamic systems.
We are living in the 21st century - get with the program and leave your old 20th century development paradigms behind. Learn your craft, and push for changes. I have had success implimenting iterative development lifecycle projects - and these projects have been under budget and on time every time - outperforming traditional models. It is an uphill battle because the 'old heads' want to keep their turf (the legions of programmers they have acquired over the intervening years) - and usually have the ear of their buddies at the top. But everyone retires, and with them will go their inefficient and ineffective design philosophies. Sadly, we will continue to flush money down the toilet with every boondoggle that comes along until they are gone.
Most MMO games (including large scale FPSs - such as WWIIonline/Battlefield Europe) evolve, and I would argue that is the future for multiplayer games of all types.
As new content is developed or old content is revamped, it is added to the mix on a continuous basis.
In fact, for open source games a pay-to-play model would probably work better than attempting to make a living on shrink-wrapped one-offs.
Actually, it could be argued that the idea of 'shrink-wrapped' software in general is on the way out as the new business models shake out. However, the profit margins will be much less than they are today because people aren't going to pay $50 to download a game, but they will pay $5 on a recurring basis for an MMO game (that in 10 months will make your original projection of $50 - and then some in the months and years that follow).
Thank you for that wonderful strawman (that both pollutes your beverages and eats your offspring). Your fallacy is making the assumption that the free 'dog' is of a lower quality than the nonfree dog.
.0001 seconds over the course of a year. Meanwhile, the vendor on the streetcorner is trying to convince you to buy a used Swatch that is far less accurate, and who's face shows numbers in Mandarin Chinese for $2000 by arguing the Rolex takes longer to put on in the morning.
A more accurate metaphor is someone has given you a free Rolex watch that keeps time accurate to
Unfortunately you don't know Mandarin.
This point hits the nail right on the head.
The idea with XML is to have a portable format that can be used by various applications/services (web, editors, and XML backend parsers).
The power with XML is that not only does it describe a document - but that it can also be parsed by search engines and meta data can be embedded which all taken together - allow your documentation to also serve as a data source for various applications - (tied to RSS feed perhaps, part of taxonomy based search engine etc..) some of which are only now being developed - and many that are just ideas.
Embedding a proprietary binary format into XML defeats the purpose of this and is, in fact, not 'open' at all.
More FUD from Redmond - why is anyone surprised by this?
Over the next 10 years you are going to see more and more buy-in of the alternatives, so much so that it will marginalize the shrink-wrapped software industry unless they change. That change will be painful to them - and may not be possible for some, because it will mean much smaller development teams that generate less overall revenue than before. Good for quality developers, bad for borderline 'wanabe' developers.
One passage in the article was telling:
This tells me that the application code is too closely coupled (monolithic code) - which unnecessarily increases complexity. The module that displays (presumably) a stream of characters should have nothing to do with the module that allows you to create a project (again making some presumptions about how such an interface would work - perhaps entering the name of the project, generating database entries or files etc...)
It doesn't have to be this way.
Instead of asking 'why don't we ship shrinkwrapped apps that are not bug free', I think we should be asking this larger question:
Why do we ship shrinkwrapped applications at all?
The model we are using is all wrong. Instead, we should be gearing our application lifecyle to handle iterative (recursive) development - releasing early and often via the network. Many pay-to-play games successfully use just such a model, updating content and patching bugs via uploads.
Add to that an agile process approach coupled with a design philosophy that emphasizes simple modules (that can be tested more completely, encorporating clearly defined APIs that don't allow undefined results to occur when external modules attempt to pass bad data) and you have a winner!
Thankfully, there are few developers who understand this concept - their continued delivery of faulty applications, that then takes more money to 'correct' (e.g. you buy the next version - which in fact has its own faults) makes me look like a CS god in comparison - and keeps me in business in areas where there is little tolerance for buggy code.
Zope3 is cooking right along. Python blows away Ruby imho - the true measure is how productive it allows you to be. I've been a longtime developer of Perl, C and Java apps - but find Python is better for me mainly due to the ease of use and ease of debugging not possible with other alternatives.
Down with the curly brace and the dollar sign!
Back in the 'good-ol' days - when you bought a piece of hardware (computer, radio, etc) included in the box was a schematics to the whole system. You could repair your own machine using the schematics if you wanted.
When did we stop doing this, and why? Are we more stupid now, than we were 30 years ago?
I agree with the parent. There is no Linux distribution that I can point to that is suitable for 'Joe User' - yet.
Before you think I am another M$ appologist -- I am a longtime Unix/Linux system administrator and developer, and have multiple machines running linux - and experience using many distributions. I am comfortable with Linux. In fact I made an effort to go 'window-less' on my home network. For my development work and keeping up on things at home, surfing the web and reading email - Linux is perfect.
The problem came when I attempted to get my large collection of MS Windows based video games working under linux. I tried Winex - which worked for some older games, but not for the newest games. I bought a subscription to Cedega and had no better luck. My particular distribution's libraries did not fully match the kernel that was running on my system, so I rebuilt the kernel to match (to get my video graphics card driver to load) - which then broke other libraries links. Cedega's dependencies were not well documented - and I would find them as I tried to get the games working.
To make a long story short, I spent months toying with it - but never got to do what I wanted to do - play my games without a hassle. So my game/media machine is now a windoze box once again; I don't have time to mess with it and accomplish the other things I want to in my short life.
I am lucky though - I have multiple machines, so if my game box decides to go down - I can get the other things done (email, web access, development) on my other machines. 'Joe User' usually doesn't have that option. His one machine has to do everything - and he definitely doesn't have time to tinker with it.
The solution as I see it is someone needs to build a Linux distribution that is geared towards Joe User 100%. He will want to play the cutting edge video games (built primarily for Windows machines) - an improved version of WINE or Cedega must be integrated with it. Libraries have to be clearly managed to avoid incompatibilities - and the user should not have to toy with it. In short everthing should 'just work' out of the box (printer setup, .
Failing that - and if you absolutely can not have Windows on your network - I would say save your pennies and spring for a MAC.
I am curious, are you making an attempt at humor, trying to be a troll, or really not capable of understanding english?