NetBSD is designed to be low footprint, highly portable, and flexible. It's the ideal BSD for embedded systems (whereas FreeBSD is suited to larger size systems and servers, and OpenBSD is unfortunately in the middle as a security oriented system, but not portable nor performance enough as NetBSD).
Licensing is a key NetBSD selling point. The problem with Linux/GNU is the GNU license which does not favour commercial embedded manufacturers who want to customise the software inside their product and (a) not have to offer the source code, and (b) not have to offer any competitive/IP/commercially-sensitive content in that source code (i.e. algorithms, device driver interfaces, etc). Despite all of the hoo-haa about the GPL, I'm afraid that companies really do like to minimise risk and lower cost by keeping their product internals as secret as possible.
Portability: NetBSD wins hands down: Linux has been ported to lots of things, but the basic architecture is not as clean. This is been shown time over again, and proven by the supported (not just "happened to be ported to") platforms of NetBSD.
NetBSD also gets to leverage the work from FreeBSD and OpenBSD, as FreeBSD really has greater commercial support in terms of device drivers and so on than either NetBSD or FreeBSD.
What NetBSD should be focusing on (in this order)
1. keeping tight BSD licenses (the kind of Theo style approach being applied to OpenBSD at the moment : to be very strict about licenses of included items) -- commercially friendly for competitive/cost reasons;
2. keeping high portability and flexibility: making sure that as new processors/platforms/drivers come along, that they can be quickly and easily supported -- commercially friendly for time to market allowing easy leverage of the existing product;
3. continually rolling in new support for hardware and security features as possible by grafting from FreeBSD and OpenBSD;
4. continually reworking and streamlining the internals to support all of the above;
5. improving the build environments (i.e. the cross compile is fantastic now), the ports system (fantastic and incredibly easy to bring third-party components in), and other things such as boot code, embedded/compressed installs, etc;
6. not getting "lost" on wasted effort for things like graphical installers, or coloured-ls's, etc;
Basically, NetBSD should continue to:
- target small/embedded devices; - continue/improve commercial friendly; - innovate/improve on reducing total effort to realise NetBSD onto a new hardware platform;
The real solution will be in the form of a petabox style device that is clustered and internally massively redundant (i.e. cluster size RAID) which is self-healing so when drives fail, you just replace it with a new one, and the cluster FS takes care of this. Unless you have a catastrophic failure, this should last for a long time.
You miss a key point that BSD has over GNU: the licensing terms are commercially friendly, because a vendor can modify and embed a BSD into a product without having to offer the source code -- and this is really important for a large number of (but not all, mind you) products.
removal of duplication is usually a good thing
on
Abandoning Header Files?
·
· Score: 2, Interesting
Just remember that a header file defines the interface to the body: which actually duplicates some of the material in the body. Because of this duplication, you can have problems, i.e. faulty build dependencies, mismatch between header/body, etc. Removing this sort of duplication is usually a good thing: so if the technology (i.e. compiler) is smart/performance/etc to get it right, then the change could be a good thing.
I'd like to point out that many other respondants have argued their case with reference to 'C', however the poster clearly said it was not 'C' -- without further information, it's difficult to know whether these 'C' type issues will translate. I'd point out that some languages, e.g. python, java, perl, do not have ideas of separate header/body -- suggesting that "current trends" in languages is to do away with the duplication.
The compiler could be intelligent enough to construct a parse tree quickly, and only resolve parts of the parse tree when necessary: so for example, if there was previously a 5K header, and a 30K body, but now only a 30K body, the compiler may read the entire 30K, and only "roughly" parse it (e.g., say for a function, it parses the outer scope of the function, but resolves nothing inside the function until some other code actually uses the function).
I don't think there's an answer for this guy: there are too many issues that haven't been stated, as we know nothing about the particular toolchain, the build environment, the language, etc. All we have an abstract concept of splitting files into header/body. That concept by itself isn't good or bad, it depends upon a lot of other issues that change the perspective.
My answer would be that surely in the guys company he has a couple of clueful senior engineers that can sit around a whiteboard and discuss (using their computer science training) what actual impact the change will have on the project, and whether to go with the impact.
"It would be silly to write a memory manager in UML."
You are just plain wrong. I've used UML to design and implement low level device drivers for embedded platform with C++ autogeneration. There's nothing in UML that causes it to produce bloaty code, and there's quite a lot of richness with the right tools (e.g. Rational ROSE) to customise the C++ code that's generated.
This has nothing to do with UML, but has more to do with you as the designer: do you know how to design performance device drivers or not ? I've been around long enough to see device driver engineers try to write applications (bad move!) and vice versa (just as bad move) to realise that it's not about the technology, it's about the design approach.
I don't think that it's about training either: it's about you actually doing some hard work and using the write design principles, which may require time and experience, but definitely does require an ability to make and learn from mistakes.
I think you're wrong: it's a design tool as well (you could be pedantic and say that it this also makes it a communication tool, but come on!). Seriously, UML as an OOA/OOD helps you scope out and bound the size and complexity of the design, so you get a clearer idea of what kind of time/effort it'll take to realise, and what order of magnitude bugs/issues you'll have to deal with later.
If you're only using UML as a communication tool, you're seriously underusing it. It's like buying a TV and using it to tune into FM radio only.
Re:I avoid it like the plague
on
How Do You Use UML?
·
· Score: 2, Insightful
You admit that this was your first experience with UML, and by the sounds of iy, you didn't get it right. Can you blame UML, or can you say that it was because it was a first project and so on. Without knowing further details, I think your attitude is bad: you had one bad experience and have let it cloud your judgement for the future. Plenty of other people have good experience with UML, whether on first or subsequent attempts, which is testimony to the fact that it does work: but of course, UML is just one part of a whole complexity of issues in a project, and perhaps it was one of those other issues that caught you out. UML isn't a silver bullet, and like most software technologies, you can't expeect it to save the day on first use: time, patience, experience and hard work bring the results.
"I remember working on a project where we made the entire structure before writing a single line of code in UML. We made it all as a team and all agreed on it. The first guy to actually started codiing it totally ignored what we made. Great! We simply wasted time! "
That's not a problem with UML, but with your team: that guy sounds completely unprofessional -- i.e. he agreed to a consensus, and then ignored it, which could happen in any circumstance, not just because UML was there.
I think you are just plain wrong, and I've actually used UML on several projects: just out of curiosity, what kind of experience do you have to back up your claims, have you used UML on actual projects, or worked near/with teams that have, are are just spouting a lot of uninformed garbage? I would mod you down if I could.
Fantastic experience with UML, Rational ROSE and C++ code generation: not only more productive, but the resulting design is far better because you're easily able to refactor while you're fleshing out the design. Typically, I've found, that once C++ implementation is underway, refactoring is hard and costly because of the amount of changes that need to be made, and the biggest issue for long term C++ code is the lack of design evolution, leading to code that has a lot of implementation hacks and quirks that could have been avoided if the higher level object model was evolved.
I see a reasonable number of useless comments from people that haven't used OOA/OOD language, but like to suggest their hypothetical ideas about the problems.
Having used UML, I've found that UML itself per-se isn't the most importnat thing, what was really the killer was Rational ROSE with UML and code-generation. The reasons are:
(a) the first pass UML diagram in Rose helped establish the "rough" design model: a pretty close OO diagram to help estimate complexity and amount of time for implementation.
(b) the code-generation is fantastic: you work through your architectural layers and components, to flesh out that initial design (and yes, 20%-40% of your rough design will be thrown away and reworked) and implement code, refactoring and adjusting as you go, in tandem with constructing unit tests to verify.
(c) afterwards, the UML diagrams in ROSE and code-generation make it easier to refactor and add/change functionality, and for new hires, the diagrams are the best documentation for the design: because they are the design, and are in sync with the code.
Employers weigh up the total sum of what you present in a CV. Other issues can outweigh you having going to a top school, e.g. track record. Additionally, going to a top school is no guarantee that you're a top student. However, when the employer weighs things up, a better school adds to the overall point count that leans in your favour, especially in comparison to other equivalent candidates (similar experience, different schools, for example). Even if you are "fresh paint" as a graduate job seeker: other issues count (e.g. you could come from a mid tier school, but you show that in the last 3 years, you've a passion for software that meant you contributed to multiple F/OSS projects, and you know your way around CVS, tools, unix, etc: employer will know they are getting a really capable and hands on person, not just someone who did well at exams).
Like most things in life: do your best to work at the highest level (i.e. going to the best schools, etc), but don't deprive yourself of a life in doing so.
The article should also address the new opportunities that arise. For example, a smart vendor could develop XORP optimised hardware platform. What this would mean is that you have the choice of:
1. free open source XORP you can run on commodity hardware, and the price is good, but the performance isn't so good;
2. free open source XORP bundled with high performance hardware, using, say, custom packet processing silicon, etc: the performance good, but the price higher.
Everyone gets to win: the hackers and low-budget market gets a fantastic software product, that is continually evolving, and the high end market gets high performance, and leverage off the low cost and community developed software itself.
Other posters have pointed out that Cisco is not just about "the product", it's about "the services". This means that Cisco could pull a Sun (e.g. open up IOS and concentrate on hardware and service delivery), or start to offer its own XORP solutions, also building upon its hardware and service delivery expertise.
The product is far from causing Cisco any problems at the moment. The good analogy is MySQL: it effectively puts low scale SQL commercial databases out of business, but the feature set, performance and other issues are not yet mature enough for it to act as a replacement for Oracle in a commercial environment. I work on a 24/7 multiple Oracle mission critical product: moving from Solaris to Linux as the platform is happening now, but only a fool would suggest we should move from Oracle to MySQL. However, in 5-10 years time, MySQL may actually present a viable alternative.
Stay tuned!
(disclaimer: my analogies are hand waving, so I might be slightly off the ball on a few points, but that should not detract from the overall gist of the message).
"There was a post on comp.sys.cbm a few weeks ago, although they have the licenses to distribute these, the actual versions included are mostly cracked games. The reason given? It was easier to NTSC-fix the cracked versions than to strip off the copy protection of the originals. "
This means that they're violating the copyright of the crackers who put their own intro loaders and code into the work. I'd like to see some crackers issue DMCA notices against the company! Just because the games are copyright by someone else doesn't invalidate the crackers claim to their own copyright. However, the company would be allowed to strip off the cracker intros and extract the original game inside to redistribute it.
Hey, read my post again: I said "customer ops", not "customers" - i.e. customer operations _internal staff_ - it goes without saying that only an idiot would tell customers that they're stupid.
Honestly, I like the fact that the guy has collected a lot of data about the problem: but leave out the conjectures: that's the job of Valve engineers to rectify the issue, your job is just to report the defect and make sure it's got enough visibility to not get swept under the carpet.
When I deal with customer issues I often find the conjectures wrong, and usually ignore them because the first thing you do is reproduce the problem or look at the debug logs or core and figure it out for yourself. In fact, once it irriated me so badly when dealing with sev1 that on an international conference call I had to tell some customer ops to stop their (what I could easily tell was uninformed and off the track discussion) conjecturing and just leave it to us as the engineers to sort out.
Firstly, I used "places in the deep south" figuratively, not literally. I'm not even an American, I've only been there a few times, so I was searching for a stereotype that would convey my meaning. Don't read my argument as being literal - I wasn't actually comparing in detail.
Secondly, I agree that it is doubtful whether the arid poverty of some third world countries will ever be present in a first world country, at least now, but don't discount it for the future: plenty of sci-fi and social circumstances could lead to a society where there is a nasty gap between the rich and the poor, even in a so-called first world country.
Thirdly, I don't profess to explain the ideas of Manuel Castells anywhere near as well as he does: his works are amazing for the grounding in actual deal and evidence (in this respect, he reminds me of Noam Chomsky). I suggest you read his works, because like you said "I have not read the book, but it does sound interesting", and like I said, I can't explain them as well.
In his trilogy on "the information age", manuel castells looked at the evolving and future structure of current society. One of his suggestions, which I remember clearly, is to forget looking at first, second and third world as being rigidly defined around countries (i.e. the idea that some are "first", others are "second", etc).
He suggests that the world is really becoming a patchwork of first, second and third - so that even so called advanced countries (on average) have third world areas, and even third world countries have first world areas. When you look at it this way, then it shouldn't be surprising about "outsourcing" from advanced economic zones (e.g. SF) to third world zones (e.g. places in the deep south).
Either way, I found this conceptual idea of his to be a very powerful one.
DECT (digital enhanced cordless telephony) is the ETSI (european) standard for cordless phones (roughly, it describes two 64K channels (I think?), and an authentication "pairing" mechanism -- in fact, Bluetooth adopted some of the architectural features of DECT).
The great thing about DECT/GAP systems is that they are interoperable: so you buy a base station, and can pair additional handsets: even if the handsets are from another manufacturer -- it really works. In the UK, a single handset DECT handset/station will set you back less than £30-50. You'll find that about 70%+ of cordless phones are DECT.
What I've been waiting for is a USB DECT dongle which acts as a DECT Fixed Part (i.e. the base system), and allows Portable Parts (i.e. handsets) to pair with it. Not only would you be able to buy off the shelf mass produced handsets which are inexpensive, but many of these handsets are stylish and fully featured. DECT chipsets are cheap and quite integrated: the physical landscape wouldn't be very large either.
This would be a very cheap and effective way to get existing and new consumers onto VOIP because it solves a large part of the problem: the existing VOIP phones are either expensive (i.e. WIFI or IP based) or ugly and cheap (i.e. USB based , etc).
Further more, because DECT architecture allows for multiple channels to be active at once (e.g. in a house, you can conference between two handsets and the channels are proxied via. the base system, kind of like HostAP mode on 802.11), a clever USB DECT could even proxy calls back to landline based upon routing profile. You could set up your VOIP router to send all local calls back out your physical land line, and it'd be transparent to you. Of course, the downside is you'd need an always on PC, but that's okay for those of us that have 24/7 low power DSL gateways (i.e. VIA or soekris).
We're talking "clustering", not "distributed" computing: i'd like to see these experiments with an OS that was designed to be distributed from the ground up, e.g. Amoeba (http://www.cs.vu.nl/pub/amoeba/).
Buy the old models as they are being discounted to make way for the new models, especially leading up to christmas or to end of financial year. You're only get a 12 month behind generation, but you generally save quite a bit, and in 12 months everything will move ahead again. It's always a moving target, so if 3-4megapixel is the current "sweet spot", why lash out for an exponentially more expensive 5-6megapixel ? Both of them are going to age in the next 12-24 months anyway.
Also, you don't have to buy the lastest and greatest and fastest. Why pay £40 for a 54Mb 11G card for a notebook when mostly you're using it to surf through to a 512K DSL connection: you might as well buy a sub £10 11B or 11B+ card for 11 or 22Mbps. The good engineer would be buying the 22Mbps card because 54Mbps is surplus to requirements. Even if you upgrade your DSL to 4-8Mbps in 2 years time, your 22Mbps card is still overkill for web access. I'd argue that for streaming audio/video: whether you're at 22Mbps or 54Mbps will not make much difference.
I was recently lectured by someone who worked in marketing in a UK HI-FI R&D company in the 1980's: his insightful comment (which must also apply to many other technologies, such as computers and mobile phones) was "the key thing we understood is that high fidelity market was not a technology market, it was a fashion market". I'd bet that a lot of slashdot readers are fashionistas more than technocrats - and I'd like to hear some ideas on what behaviours distinguish each type of person.
I'm looking forward to reading the various replies: but honestly, just do as you please. If you're a gadget freak, then upgrade whenever you want the latest. If you're not, then wait until breakage or functionality is required.
For example, I've had a GSM phone here in the UK for the last 6 years: initially a motorola tri-band that was part of a no initial cost 12 month lock-in contract in 1998: it served me well until 2003, until I took option on a free upgrade to sony ericson T68i (I'd been getting text-messages about free upgrades for 18 months or so, and finally decided to act) - I even got £20 cash back on sending back the old phone! I don't plan to upgrade again for another 3-4 years or more - that'll be 10 years without paying for a phone; and I'm still on a cheap plan from 2001 for low cost calls:-). I don't need to surf the web on a postage stamp, nor take 1mpixel pictures.
On the other hand, guys I work with have been through the latest and greatest phones every 12-18 months or so - buying expensive camera/colour models. Sure they are nice and snazzy, but honestly, they don't seem to really use all the extra functionality other than as occasional toy. But, it seems to keep them happy. It keeps me happy knowing they're helping drive the technology forward until I decide to upgrade;-).
Back to my hand, I do spend ~£500 a month at good restaurants here in London because that's my thing: when taking to one of these constant upgrade guys once, they couldn't understand why anyone would pay more than £30 for a meal.
It takes all kinds! Just do what makes you happy and just ensure that you're not doing something you might regret such as throwing away 10 years of money on frivolous toys - some people actually have no regrets about this type of thing, I would.
"A law like this in North America would cause warranties to default to zero. All products would be labelled "As Is" to reduce liability."
"Trust me on that."
I can't: that would not work, because the law would prevent the manufacturer from contracting out of the warranty. Don't you understand that's the reason for making it a law - to stop the manufacturer from getting out of a warranty period?
"I'm a retailer myself and we get plenty of garbage products in from manufacturers that we know will welch on their warranty that get labelled like that by us as is (BIG fluorescent sticker, too)."
This is _why_ such a law is needed: although the manufacturer would be liable, it also puts pressure on you as the retailer to stop accepting shonky goods.
"You'd think that would deter customers from buying them, but nooo... "
Customers are not always smart. Giorgio Armani famously said "my customers aren't rich enough to buy cheap clothes": in other words, quality ultimately pays for itself.
"the customers demand them ($15 CDN power supplies, sub $180 CDN satellite receivers, etc, etc). "
Customers demand lots of things, they don't get anything. If the extended warranty costs a bit more on the product, then tough, the customers have to wear it, because in the long run, it works out better for all of us (more reliable products, manufacturers producing better quality, less obsolesence, etc).
"I don't want to sell them, but I'm a store. I'm there to serve the public, and make a good wage doing that. So you sell what you're told (by customers) to sell."
You're mistaken: you're just a middleman between the manufacturer and the customer. You're only selling things to the customer because the manufacturer made them available. If the manufacturer stops making shonky goods available, then customers will just have to accept better quality.
It may be the customers "right" to buy low quality goods, but honestly, I think we're in a civilised world, and to make it a better place to live, it sounds entirely fair to set some minimum standards: 90 day warranties are simply too short, 12 months sounds more appropriate. How many people buy consumer electronics and only expect it to last 90 days? I certainly don't. And if I buy something that fails after 120 days, I certainly want to be able to return it to the manufacturer.
Slashdot Mirror
This is really a no brainer,
NetBSD is designed to be low footprint, highly portable, and flexible. It's the ideal BSD for embedded systems (whereas FreeBSD is suited to larger size systems and servers, and OpenBSD is unfortunately in the middle as a security oriented system, but not portable nor performance enough as NetBSD).
Licensing is a key NetBSD selling point. The problem with Linux/GNU is the GNU license which does not favour commercial embedded manufacturers who want to customise the software inside their product and (a) not have to offer the source code, and (b) not have to offer any competitive/IP/commercially-sensitive content in that source code (i.e. algorithms, device driver interfaces, etc). Despite all of the hoo-haa about the GPL, I'm afraid that companies really do like to minimise risk and lower cost by keeping their product internals as secret as possible.
Portability: NetBSD wins hands down: Linux has been ported to lots of things, but the basic architecture is not as clean. This is been shown time over again, and proven by the supported (not just "happened to be ported to") platforms of NetBSD.
NetBSD also gets to leverage the work from FreeBSD and OpenBSD, as FreeBSD really has greater commercial support in terms of device drivers and so on than either NetBSD or FreeBSD.
What NetBSD should be focusing on (in this order)
1. keeping tight BSD licenses (the kind of Theo style approach being applied to OpenBSD at the moment : to be very strict about licenses of included items) -- commercially friendly for competitive/cost reasons;
2. keeping high portability and flexibility: making sure that as new processors/platforms/drivers come along, that they can be quickly and easily supported -- commercially friendly for time to market allowing easy leverage of the existing product;
3. continually rolling in new support for hardware and security features as possible by grafting from FreeBSD and OpenBSD;
4. continually reworking and streamlining the internals to support all of the above;
5. improving the build environments (i.e. the cross compile is fantastic now), the ports system (fantastic and incredibly easy to bring third-party components in), and other things such as boot code, embedded/compressed installs, etc;
6. not getting "lost" on wasted effort for things like graphical installers, or coloured-ls's, etc;
Basically, NetBSD should continue to
- target small/embedded devices;
- continue/improve commercial friendly;
- innovate/improve on reducing total effort to realise NetBSD onto a new hardware platform;
The real solution will be in the form of a petabox style device that is clustered and internally massively redundant (i.e. cluster size RAID) which is self-healing so when drives fail, you just replace it with a new one, and the cluster FS takes care of this. Unless you have a catastrophic failure, this should last for a long time.
You miss a key point that BSD has over GNU: the licensing terms are commercially friendly, because a vendor can modify and embed a BSD into a product without having to offer the source code -- and this is really important for a large number of (but not all, mind you) products.
Just remember that a header file defines the interface to the body: which actually duplicates some of the material in the body. Because of this duplication, you can have problems, i.e. faulty build dependencies, mismatch between header/body, etc. Removing this sort of duplication is usually a good thing: so if the technology (i.e. compiler) is smart/performance/etc to get it right, then the change could be a good thing.
I'd like to point out that many other respondants have argued their case with reference to 'C', however the poster clearly said it was not 'C' -- without further information, it's difficult to know whether these 'C' type issues will translate. I'd point out that some languages, e.g. python, java, perl, do not have ideas of separate header/body -- suggesting that "current trends" in languages is to do away with the duplication.
The compiler could be intelligent enough to construct a parse tree quickly, and only resolve parts of the parse tree when necessary: so for example, if there was previously a 5K header, and a 30K body, but now only a 30K body, the compiler may read the entire 30K, and only "roughly" parse it (e.g., say for a function, it parses the outer scope of the function, but resolves nothing inside the function until some other code actually uses the function).
I don't think there's an answer for this guy: there are too many issues that haven't been stated, as we know nothing about the particular toolchain, the build environment, the language, etc. All we have an abstract concept of splitting files into header/body. That concept by itself isn't good or bad, it depends upon a lot of other issues that change the perspective.
My answer would be that surely in the guys company he has a couple of clueful senior engineers that can sit around a whiteboard and discuss (using their computer science training) what actual impact the change will have on the project, and whether to go with the impact.
"It would be silly to write a memory manager in UML."
You are just plain wrong. I've used UML to design and implement low level device drivers for embedded platform with C++ autogeneration. There's nothing in UML that causes it to produce bloaty code, and there's quite a lot of richness with the right tools (e.g. Rational ROSE) to customise the C++ code that's generated.
This has nothing to do with UML, but has more to do with you as the designer: do you know how to design performance device drivers or not ? I've been around long enough to see device driver engineers try to write applications (bad move!) and vice versa (just as bad move) to realise that it's not about the technology, it's about the design approach.
I don't think that it's about training either: it's about you actually doing some hard work and using the write design principles, which may require time and experience, but definitely does require an ability to make and learn from mistakes.
I think that this is one of the most insightful comments here.
"Its a communication tool. Thats all."
I think you're wrong: it's a design tool as well (you could be pedantic and say that it this also makes it a communication tool, but come on!). Seriously, UML as an OOA/OOD helps you scope out and bound the size and complexity of the design, so you get a clearer idea of what kind of time/effort it'll take to realise, and what order of magnitude bugs/issues you'll have to deal with later.
If you're only using UML as a communication tool, you're seriously underusing it. It's like buying a TV and using it to tune into FM radio only.
You admit that this was your first experience with UML, and by the sounds of iy, you didn't get it right. Can you blame UML, or can you say that it was because it was a first project and so on. Without knowing further details, I think your attitude is bad: you had one bad experience and have let it cloud your judgement for the future. Plenty of other people have good experience with UML, whether on first or subsequent attempts, which is testimony to the fact that it does work: but of course, UML is just one part of a whole complexity of issues in a project, and perhaps it was one of those other issues that caught you out. UML isn't a silver bullet, and like most software technologies, you can't expeect it to save the day on first use: time, patience, experience and hard work bring the results.
"I remember working on a project where we made the entire structure before writing a single line of code in UML. We made it all as a team and all agreed on it. The first guy to actually started codiing it totally ignored what we made. Great! We simply wasted time! "
That's not a problem with UML, but with your team: that guy sounds completely unprofessional -- i.e. he agreed to a consensus, and then ignored it, which could happen in any circumstance, not just because UML was there.
I think you are just plain wrong, and I've actually used UML on several projects: just out of curiosity, what kind of experience do you have to back up your claims, have you used UML on actual projects, or worked near/with teams that have, are are just spouting a lot of uninformed garbage? I would mod you down if I could.
Fantastic experience with UML, Rational ROSE and C++ code generation: not only more productive, but the resulting design is far better because you're easily able to refactor while you're fleshing out the design. Typically, I've found, that once C++ implementation is underway, refactoring is hard and costly because of the amount of changes that need to be made, and the biggest issue for long term C++ code is the lack of design evolution, leading to code that has a lot of implementation hacks and quirks that could have been avoided if the higher level object model was evolved.
I see a reasonable number of useless comments from people that haven't used OOA/OOD language, but like to suggest their hypothetical ideas about the problems.
Having used UML, I've found that UML itself per-se isn't the most importnat thing, what was really the killer was Rational ROSE with UML and code-generation. The reasons are:
(a) the first pass UML diagram in Rose helped establish the "rough" design model: a pretty close OO diagram to help estimate complexity and amount of time for implementation.
(b) the code-generation is fantastic: you work through your architectural layers and components, to flesh out that initial design (and yes, 20%-40% of your rough design will be thrown away and reworked) and implement code, refactoring and adjusting as you go, in tandem with constructing unit tests to verify.
(c) afterwards, the UML diagrams in ROSE and code-generation make it easier to refactor and add/change functionality, and for new hires, the diagrams are the best documentation for the design: because they are the design, and are in sync with the code.
Employers weigh up the total sum of what you present in a CV. Other issues can outweigh you having going to a top school, e.g. track record. Additionally, going to a top school is no guarantee that you're a top student. However, when the employer weighs things up, a better school adds to the overall point count that leans in your favour, especially in comparison to other equivalent candidates (similar experience, different schools, for example). Even if you are "fresh paint" as a graduate job seeker: other issues count (e.g. you could come from a mid tier school, but you show that in the last 3 years, you've a passion for software that meant you contributed to multiple F/OSS projects, and you know your way around CVS, tools, unix, etc: employer will know they are getting a really capable and hands on person, not just someone who did well at exams).
Like most things in life: do your best to work at the highest level (i.e. going to the best schools, etc), but don't deprive yourself of a life in doing so.
The article should also address the new opportunities that arise. For example, a smart vendor could develop XORP optimised hardware platform. What this would mean is that you have the choice of:
1. free open source XORP you can run on commodity hardware, and the price is good, but the performance isn't so good;
2. free open source XORP bundled with high performance hardware, using, say, custom packet processing silicon, etc: the performance good, but the price higher.
Everyone gets to win: the hackers and low-budget market gets a fantastic software product, that is continually evolving, and the high end market gets high performance, and leverage off the low cost and community developed software itself.
Other posters have pointed out that Cisco is not just about "the product", it's about "the services". This means that Cisco could pull a Sun (e.g. open up IOS and concentrate on hardware and service delivery), or start to offer its own XORP solutions, also building upon its hardware and service delivery expertise.
The product is far from causing Cisco any problems at the moment. The good analogy is MySQL: it effectively puts low scale SQL commercial databases out of business, but the feature set, performance and other issues are not yet mature enough for it to act as a replacement for Oracle in a commercial environment. I work on a 24/7 multiple Oracle mission critical product: moving from Solaris to Linux as the platform is happening now, but only a fool would suggest we should move from Oracle to MySQL. However, in 5-10 years time, MySQL may actually present a viable alternative.
Stay tuned!
(disclaimer: my analogies are hand waving, so I might be slightly off the ball on a few points, but that should not detract from the overall gist of the message).
"There was a post on comp.sys.cbm a few weeks ago, although they have the licenses to distribute these, the actual versions included are mostly cracked games. The reason given? It was easier to NTSC-fix the cracked versions than to strip off the copy protection of the originals. "
This means that they're violating the copyright of the crackers who put their own intro loaders and code into the work. I'd like to see some crackers issue DMCA notices against the company! Just because the games are copyright by someone else doesn't invalidate the crackers claim to their own copyright. However, the company would be allowed to strip off the cracker intros and extract the original game inside to redistribute it.
Hey, read my post again: I said "customer ops", not "customers" - i.e. customer operations _internal staff_ - it goes without saying that only an idiot would tell customers that they're stupid.
Honestly, I like the fact that the guy has collected a lot of data about the problem: but leave out the conjectures: that's the job of Valve engineers to rectify the issue, your job is just to report the defect and make sure it's got enough visibility to not get swept under the carpet.
When I deal with customer issues I often find the conjectures wrong, and usually ignore them because the first thing you do is reproduce the problem or look at the debug logs or core and figure it out for yourself. In fact, once it irriated me so badly when dealing with sev1 that on an international conference call I had to tell some customer ops to stop their (what I could easily tell was uninformed and off the track discussion) conjecturing and just leave it to us as the engineers to sort out.
Firstly, I used "places in the deep south" figuratively, not literally. I'm not even an American, I've only been there a few times, so I was searching for a stereotype that would convey my meaning. Don't read my argument as being literal - I wasn't actually comparing in detail.
Secondly, I agree that it is doubtful whether the arid poverty of some third world countries will ever be present in a first world country, at least now, but don't discount it for the future: plenty of sci-fi and social circumstances could lead to a society where there is a nasty gap between the rich and the poor, even in a so-called first world country.
Thirdly, I don't profess to explain the ideas of Manuel Castells anywhere near as well as he does: his works are amazing for the grounding in actual deal and evidence (in this respect, he reminds me of Noam Chomsky). I suggest you read his works, because like you said "I have not read the book, but it does sound interesting", and like I said, I can't explain them as well.
In his trilogy on "the information age", manuel castells looked at the evolving and future structure of current society. One of his suggestions, which I remember clearly, is to forget looking at first, second and third world as being rigidly defined around countries (i.e. the idea that some are "first", others are "second", etc).
He suggests that the world is really becoming a patchwork of first, second and third - so that even so called advanced countries (on average) have third world areas, and even third world countries have first world areas. When you look at it this way, then it shouldn't be surprising about "outsourcing" from advanced economic zones (e.g. SF) to third world zones (e.g. places in the deep south).
Either way, I found this conceptual idea of his to be a very powerful one.
DECT (digital enhanced cordless telephony) is the ETSI (european) standard for cordless phones (roughly, it describes two 64K channels (I think?), and an authentication "pairing" mechanism -- in fact, Bluetooth adopted some of the architectural features of DECT).
The great thing about DECT/GAP systems is that they are interoperable: so you buy a base station, and can pair additional handsets: even if the handsets are from another manufacturer -- it really works. In the UK, a single handset DECT handset/station will set you back less than £30-50. You'll find that about 70%+ of cordless phones are DECT.
What I've been waiting for is a USB DECT dongle which acts as a DECT Fixed Part (i.e. the base system), and allows Portable Parts (i.e. handsets) to pair with it. Not only would you be able to buy off the shelf mass produced handsets which are inexpensive, but many of these handsets are stylish and fully featured. DECT chipsets are cheap and quite integrated: the physical landscape wouldn't be very large either.
This would be a very cheap and effective way to get existing and new consumers onto VOIP because it solves a large part of the problem: the existing VOIP phones are either expensive (i.e. WIFI or IP based) or ugly and cheap (i.e. USB based , etc).
Further more, because DECT architecture allows for multiple channels to be active at once (e.g. in a house, you can conference between two handsets and the channels are proxied via. the base system, kind of like HostAP mode on 802.11), a clever USB DECT could even proxy calls back to landline based upon routing profile. You could set up your VOIP router to send all local calls back out your physical land line, and it'd be transparent to you. Of course, the downside is you'd need an always on PC, but that's okay for those of us that have 24/7 low power DSL gateways (i.e. VIA or soekris).
We're talking "clustering", not "distributed" computing: i'd like to see these experiments with an OS that was designed to be distributed from the ground up, e.g. Amoeba (http://www.cs.vu.nl/pub/amoeba/).
Buy the old models as they are being discounted to make way for the new models, especially leading up to christmas or to end of financial year. You're only get a 12 month behind generation, but you generally save quite a bit, and in 12 months everything will move ahead again. It's always a moving target, so if 3-4megapixel is the current "sweet spot", why lash out for an exponentially more expensive 5-6megapixel ? Both of them are going to age in the next 12-24 months anyway.
Also, you don't have to buy the lastest and greatest and fastest. Why pay £40 for a 54Mb 11G card for a notebook when mostly you're using it to surf through to a 512K DSL connection: you might as well buy a sub £10 11B or 11B+ card for 11 or 22Mbps. The good engineer would be buying the 22Mbps card because 54Mbps is surplus to requirements. Even if you upgrade your DSL to 4-8Mbps in 2 years time, your 22Mbps card is still overkill for web access. I'd argue that for streaming audio/video: whether you're at 22Mbps or 54Mbps will not make much difference.
I was recently lectured by someone who worked in marketing in a UK HI-FI R&D company in the 1980's: his insightful comment (which must also apply to many other technologies, such as computers and mobile phones) was "the key thing we understood is that high fidelity market was not a technology market, it was a fashion market". I'd bet that a lot of slashdot readers are fashionistas more than technocrats - and I'd like to hear some ideas on what behaviours distinguish each type of person.
I'm looking forward to reading the various replies: but honestly, just do as you please. If you're a gadget freak, then upgrade whenever you want the latest. If you're not, then wait until breakage or functionality is required.
For example, I've had a GSM phone here in the UK for the last 6 years: initially a motorola tri-band that was part of a no initial cost 12 month lock-in contract in 1998: it served me well until 2003, until I took option on a free upgrade to sony ericson T68i (I'd been getting text-messages about free upgrades for 18 months or so, and finally decided to act) - I even got £20 cash back on sending back the old phone! I don't plan to upgrade again for another 3-4 years or more - that'll be 10 years without paying for a phone; and I'm still on a cheap plan from 2001 for low cost calls
On the other hand, guys I work with have been through the latest and greatest phones every 12-18 months or so - buying expensive camera/colour models. Sure they are nice and snazzy, but honestly, they don't seem to really use all the extra functionality other than as occasional toy. But, it seems to keep them happy. It keeps me happy knowing they're helping drive the technology forward until I decide to upgrade
Back to my hand, I do spend ~£500 a month at good restaurants here in London because that's my thing: when taking to one of these constant upgrade guys once, they couldn't understand why anyone would pay more than £30 for a meal.
It takes all kinds! Just do what makes you happy and just ensure that you're not doing something you might regret such
as throwing away 10 years of money on frivolous toys - some people actually have no regrets about this type of thing, I would.
"A law like this in North America would cause warranties to default to zero. All products would be labelled "As Is" to reduce liability."
"Trust me on that."
I can't: that would not work, because the law would prevent the manufacturer from contracting out of the warranty. Don't you understand that's the reason for making it a law - to stop the manufacturer from getting out of a warranty period?
"I'm a retailer myself and we get plenty of garbage products in from manufacturers that we know will welch on their warranty that get labelled like that by us as is (BIG fluorescent sticker, too)."
This is _why_ such a law is needed: although the manufacturer would be liable, it also puts pressure on you as the retailer to stop accepting shonky goods.
"You'd think that would deter customers from buying them, but nooo... "
Customers are not always smart. Giorgio Armani famously said "my customers aren't rich enough to buy cheap clothes": in other words, quality ultimately pays for itself.
"the customers demand them ($15 CDN power supplies, sub $180 CDN satellite receivers, etc, etc). "
Customers demand lots of things, they don't get anything. If the extended warranty costs a bit more on the product, then tough, the customers have to wear it, because in the long run, it works out better for all of us (more reliable products, manufacturers producing better quality, less obsolesence, etc).
"I don't want to sell them, but I'm a store. I'm there to serve the public, and make a good wage doing that. So you sell what you're told (by customers) to sell."
You're mistaken: you're just a middleman between the manufacturer and the customer. You're only selling things to the customer because the manufacturer made them available. If the manufacturer stops making shonky goods available, then customers will just have to accept better quality.
It may be the customers "right" to buy low quality goods, but honestly, I think we're in a civilised world, and to make it a better place to live, it sounds entirely fair to set some minimum standards: 90 day warranties are simply too short, 12 months sounds more appropriate. How many people buy consumer electronics and only expect it to last 90 days? I certainly don't. And if I buy something that fails after 120 days, I certainly want to be able to return it to the manufacturer.