Whatever happened to holding the people who exploit vulnerabilities responsible?
That's too easy. What you want to do is cut the amount of money you put into the education system, blame the education system for a bad job, then complain about the quality of coders out there and then jail themn because of the management decisions. Remember you want to look tough on crime, not sissy on this education thing;)
Anyhow lawyers are getting bored and need someone else to rape, uh sue, for money.
There are plenty of third party clients, like Adium mentioned previously or Fire. When the official messenger client, for the given messenger system, on your platform only supports text chat, then you have nothing to lose by going with multi-messenger client.
As long as we can all communicate and don't have to pay to do so, then I really can't see too much of an issue with this.
What I would like to see is active adoption of Jabber by the big players. Jabber for the most part is still like Ogg Vorbis: "interesting, but who's using it?". Google using it is certainly helping push its adoption, but at this point in time I haven't heard of any ISPs, or Fortune 500 companies, actively taking it up and connecting. Apple has also chipped into the effort, by providing a Jabber server as part of MacOS X, but how long before we see that rub off I am not sure.
Voice chat and video chat are the next two aspects that need to become part of the Jabber portfolio and adopted.
Looking at the road ahead voice chat is going to be migrate into telephony, but before it does certain things must happen first. Telephony needs to support emergency services, until then players like Google will state 'this is not a telephony service', in order to avoid FTC type regulations. The steps I see are:
building a large 'voice chat' network, with no single player controlling all the communications
working out a way for nodes to identified geographically. Remember the geographical identification should be controlled by the user, so that they can decide when to advertise their location
incorporate emergency service support
Declare that yes the are now indeed a telephony servce
We can't predict what the future will hold, but we can influence the journey getting there.
Even if Micron was able to provide able with a good price, would they have been have been able to produce NAND chips in the amounts that Apple needed. Apple has been bitten many times by supply issues, because of suppliers not being able to keep up. The three things that are important, IMO are:
- price
- yield
- product evolution, ie what upgrade is the product going to get
I thought about this the other day, asking myself why we can't have the same approach in software development as bridge building, or other engineering disciplines. The difference seems to be that of prototypes. When you build a bridge you create a prototype, test it as much as possible, tweak it where necessary and let the cycle continue until there is a working solution. Once that is done you are ready to build the bridge, based on specifications that in a certain sense are easier to follow than what software does.
Look at software and ask yourself where that prototype is, that can tweaked reworked until all obvious and so obvious issues have been tested for? You will end up noticing that the prototype and the final product is the same thing. While a bridge can be tested based on a number of complex mathematical formula, I am not so sure that software can be tested in the same way. Software is designed and developed based on a number of philosophies and sometimes these even have to interface with other programs based on other philosophies. Over time the complexity grows to a point where testing it 100% is like trying to predict what the stock market is going to do next week. I would like to give a figure to what we are able to predict, but that I will leave that for someone else, since I am not sure I am qualified to do so.
At the same time I will say that there are a good number of things for which you can create unit tests for and these help avoid the most obvious issues. The non-obvious issues, based on difficult to reproduce scenarios, variable dependencies are a little trickier.
Things are also improving thanks to libraries that implement much in the way of reusable code, but here too there is an issue. Imagine that you designed your program to be dependent on libraries x, y and z, and then the user adds libraries that effect the libraries you depend on, how can you predict what is going to happen?
You will notice that most mission critical systems are designed to have only the most essential features (as compared to desktop software) and are often coded with very precise memory management and sometimes even avoid the pointer type and instead using only primitives. Trying to develop most applications this way would be long and laborious and your users would be complaining that his complex office software doesn't do what (s)he wants (remember they can't agree on what they want), even if it is 99.999% stable.
I am not saying it is impossible, its just that I have yet to see an approach that is 100% effective and for 100% of cases. Yes I am a software developer, so I do have a certain bias.
Five minutes startup times is also a myth. Most small to medium size Java application I have start in under a minute. Of course the more dependencies and the larger the application the more time it will take. I suppose we could compare this to you average game, written in C/C++, which can take over two minutes before you are ready to go.
For an enterprise application, running as a server, start-up time is not really an issue. What does matter is ho well it does once it is running.
The truth is in IT you are usually a lot better off than in most other technology markets. Most companies in this domain announce a new product, but there is no requirement for them to do so. I am basing this on the fact that you almost never hear about a company releasing a tweaked version of a TV or Hi-Fi. Major releases maybe, but certainly not a tweak, which is what this amounts to.
You know when you are buying technology that it will be out of date before you even get it home. These people ordered something, based on specification that had agreed upon.
On the other hand I would certainly agree that it would have been better PR if Apple had lowered the price of the current offering before tweaking the specs.
If you are storing your music collection as MP3s, then 80MB is a lot. On the other hand if you store your music collection is FLAC or ALE (Apple Lossless Encoding), then the extra storage space is useful.
The question really to be asking is whether people are actually using the larger iPods in the same manner as the smaller iPods. For example are they using it for photos, personal data, movies (even if they can't be player) and other large files.
Other than drivers NOTHING should be installed in/System. This is what/Library is for. You can install frameworks in two places:
/Library/Frameworks
~/Library/Framworks
If the library is not being installed as a framwork, then it should be part of the application bundle. In fact, you can even make it so that a framework is part of application bundle.
The nice thing about frameworks is that they can include multiple versions of the same library and generally include the necessary C headers, so that developers have everything they need to write an application. They can also support localisable language files too.
The printer device is probably to allow other applications to have a PDF printer. The only question I have is what Adobe's offers over the standard PDF printing support?
As far as file format go I would go for RTF over Word format and if you only have data in your spreadsheets (as opposed to equations and images), then plain old CSV should do the job. Remember you want the lowest common denominator, so that you can read your files, with whatever hardware is available.
The question to be asked is what sort of emergency are you preparing for. Only then could you decide to what extremes to go. For example, is it just leaving a city in a hurry, dealing with a nation wide disaster or something else?
Following up on my own comment some of you may be interested by the fact a social security dog tag was once proposed. This was at the time when they were still deciding on how to implement SSNs.
You could kill two birds with one stone, and get an iPod. That way you will not only have all of your important stuff, but you'll be able to groove to some sweet tunes while looting and pillaging.
Well in the case of an emergency, this has an added benefit, since it has a screen on it. The iPod allows you to store notes on it in text format. I also believe the iPod Nano can be locked, Remember in an emergency you can't guarantee the presence of a computer or power. So the other thing to carry is a small portable solar panel to charge it.
I tend to prefer the simpler solution of paper or even engraved metal. You could always have a army sttle dog tag with your essential information engraved on it. Then you can always wear it and you would not need to worry about having to lose or encrypt that important info.
While the totally spec-less approach is not good, neither is the over speced approach. How much of each all depends on the project at hand and also what supporting tools are available.
Many people say that engineers do everything by spec, but this is not altogether true. If you are talking about the production of the final product, then yes they do. But before that there are usually prototypes that get developed, modified and tweaked, trialled and so on, until a suitable solution is worked out.
This is where software differs. How many times have you seen a company build a software prototype, build a spec based on what was discovered and then build the final product? In nearly 100% of the cases that I have seen there is no prototype, so the final product is a prototype onto itself, but one that is worked on until it becomes a final product. While a spec can layout the essential design and even at some points make a good job of making the product work, if they aren't modified to reflect the changing realities, then their is an issue.
Remember you can have a grand design that looks good on paper, but performs terribly in reality. On the other hand you could start coding straight away and be so swamped that your realise a road-map would have been useful.
Reading the comments on the blog site, I see that they mention that one advantage of being able to create a PDF straight from Office, as opposed to a print driver, is that it will maintain any embedded links that were in the original document. Maybe we will see a native PDF printer in Vista as well, though if Office an add extra stuff to the PDF, like relative links (for indexes, contents pages, etc) and even side-bar links, then it would certainly be a useful plus. I wonder, whether you could make it so a system wider printer driver could support all that?
Whatever the truth, one thing that really bothers me is the corporate users of Office. For example, you send them a document in PDF format and they insist on having a Word format. This is especially true for CVs.
The record labels are biting the hand that feeds them.
They bite the vendors, and they screw everyone else, including the artists and the buyers. If this is not monopoly abuse then I don't know what is. I think your average drugs dealers is a bit better than these guys - even they aren't, at least the law knows how deal with drugs dealers.
From reading the FAQ on the Blu-ray.com web site (not same as Blue-ray association) there are already players supporting Blu-ray in Japan, but we are unlikely to see them in North America until 2006.
Slashdot Mirror
Whatever happened to holding the people who exploit vulnerabilities responsible?
;)
That's too easy. What you want to do is cut the amount of money you put into the education system, blame the education system for a bad job, then complain about the quality of coders out there and then jail themn because of the management decisions. Remember you want to look tough on crime, not sissy on this education thing
Anyhow lawyers are getting bored and need someone else to rape, uh sue, for money.
There are plenty of third party clients, like Adium mentioned previously or Fire. When the official messenger client, for the given messenger system, on your platform only supports text chat, then you have nothing to lose by going with multi-messenger client.
What I would like to see is active adoption of Jabber by the big players. Jabber for the most part is still like Ogg Vorbis: "interesting, but who's using it?". Google using it is certainly helping push its adoption, but at this point in time I haven't heard of any ISPs, or Fortune 500 companies, actively taking it up and connecting. Apple has also chipped into the effort, by providing a Jabber server as part of MacOS X, but how long before we see that rub off I am not sure.
Voice chat and video chat are the next two aspects that need to become part of the Jabber portfolio and adopted.
Looking at the road ahead voice chat is going to be migrate into telephony, but before it does certain things must happen first. Telephony needs to support emergency services, until then players like Google will state 'this is not a telephony service', in order to avoid FTC type regulations. The steps I see are:
We can't predict what the future will hold, but we can influence the journey getting there.
Even if Micron was able to provide able with a good price, would they have been have been able to produce NAND chips in the amounts that Apple needed. Apple has been bitten many times by supply issues, because of suppliers not being able to keep up. The three things that are important, IMO are:
- price
- yield
- product evolution, ie what upgrade is the product going to get
Andre
I thought about this the other day, asking myself why we can't have the same approach in software development as bridge building, or other engineering disciplines. The difference seems to be that of prototypes. When you build a bridge you create a prototype, test it as much as possible, tweak it where necessary and let the cycle continue until there is a working solution. Once that is done you are ready to build the bridge, based on specifications that in a certain sense are easier to follow than what software does.
Look at software and ask yourself where that prototype is, that can tweaked reworked until all obvious and so obvious issues have been tested for? You will end up noticing that the prototype and the final product is the same thing. While a bridge can be tested based on a number of complex mathematical formula, I am not so sure that software can be tested in the same way. Software is designed and developed based on a number of philosophies and sometimes these even have to interface with other programs based on other philosophies. Over time the complexity grows to a point where testing it 100% is like trying to predict what the stock market is going to do next week. I would like to give a figure to what we are able to predict, but that I will leave that for someone else, since I am not sure I am qualified to do so.
At the same time I will say that there are a good number of things for which you can create unit tests for and these help avoid the most obvious issues. The non-obvious issues, based on difficult to reproduce scenarios, variable dependencies are a little trickier.
Things are also improving thanks to libraries that implement much in the way of reusable code, but here too there is an issue. Imagine that you designed your program to be dependent on libraries x, y and z, and then the user adds libraries that effect the libraries you depend on, how can you predict what is going to happen?
You will notice that most mission critical systems are designed to have only the most essential features (as compared to desktop software) and are often coded with very precise memory management and sometimes even avoid the pointer type and instead using only primitives. Trying to develop most applications this way would be long and laborious and your users would be complaining that his complex office software doesn't do what (s)he wants (remember they can't agree on what they want), even if it is 99.999% stable.
I am not saying it is impossible, its just that I have yet to see an approach that is 100% effective and for 100% of cases. Yes I am a software developer, so I do have a certain bias.
The site seems to be here: http://emulation.victoly.com/ Must admit I couldn't find any Lisa emulators on the site, but did find this link: http://lisa.sunder.net/
I would have pointed you to emulation.net, but it appears to be resolving to 127.0.0.1!?
That's where in Java, things like WeakHashMaps come in useful.
Five minutes startup times is also a myth. Most small to medium size Java application I have start in under a minute. Of course the more dependencies and the larger the application the more time it will take. I suppose we could compare this to you average game, written in C/C++, which can take over two minutes before you are ready to go.
For an enterprise application, running as a server, start-up time is not really an issue. What does matter is ho well it does once it is running.
The truth is in IT you are usually a lot better off than in most other technology markets. Most companies in this domain announce a new product, but there is no requirement for them to do so. I am basing this on the fact that you almost never hear about a company releasing a tweaked version of a TV or Hi-Fi. Major releases maybe, but certainly not a tweak, which is what this amounts to.
You know when you are buying technology that it will be out of date before you even get it home. These people ordered something, based on specification that had agreed upon.
On the other hand I would certainly agree that it would have been better PR if Apple had lowered the price of the current offering before tweaking the specs.
If you are storing your music collection as MP3s, then 80MB is a lot. On the other hand if you store your music collection is FLAC or ALE (Apple Lossless Encoding), then the extra storage space is useful.
The question really to be asking is whether people are actually using the larger iPods in the same manner as the smaller iPods. For example are they using it for photos, personal data, movies (even if they can't be player) and other large files.
Not to mention the fresh assault on our landfills that this disc format will make!
:)
Now I understand them buying a stake in AOL
The nice thing about frameworks is that they can include multiple versions of the same library and generally include the necessary C headers, so that developers have everything they need to write an application. They can also support localisable language files too.
BTW SDL can be found at http://www.libsdl.org/
The printer device is probably to allow other applications to have a PDF printer. The only question I have is what Adobe's offers over the standard PDF printing support?
Why stop there, why not introduce robotic students and then just do away with people completely.
As far as file format go I would go for RTF over Word format and if you only have data in your spreadsheets (as opposed to equations and images), then plain old CSV should do the job. Remember you want the lowest common denominator, so that you can read your files, with whatever hardware is available.
The question to be asked is what sort of emergency are you preparing for. Only then could you decide to what extremes to go. For example, is it just leaving a city in a hurry, dealing with a nation wide disaster or something else?
Following up on my own comment some of you may be interested by the fact a social security dog tag was once proposed. This was at the time when they were still deciding on how to implement SSNs.
You could kill two birds with one stone, and get an iPod. That way you will not only have all of your important stuff, but you'll be able to groove to some sweet tunes while looting and pillaging.
Well in the case of an emergency, this has an added benefit, since it has a screen on it. The iPod allows you to store notes on it in text format. I also believe the iPod Nano can be locked, Remember in an emergency you can't guarantee the presence of a computer or power. So the other thing to carry is a small portable solar panel to charge it.
I tend to prefer the simpler solution of paper or even engraved metal. You could always have a army sttle dog tag with your essential information engraved on it. Then you can always wear it and you would not need to worry about having to lose or encrypt that important info.
Judging by the external design, looks like the electronic engineers was asked to do someone else's job.
While the totally spec-less approach is not good, neither is the over speced approach. How much of each all depends on the project at hand and also what supporting tools are available.
Many people say that engineers do everything by spec, but this is not altogether true. If you are talking about the production of the final product, then yes they do. But before that there are usually prototypes that get developed, modified and tweaked, trialled and so on, until a suitable solution is worked out.
This is where software differs. How many times have you seen a company build a software prototype, build a spec based on what was discovered and then build the final product? In nearly 100% of the cases that I have seen there is no prototype, so the final product is a prototype onto itself, but one that is worked on until it becomes a final product. While a spec can layout the essential design and even at some points make a good job of making the product work, if they aren't modified to reflect the changing realities, then their is an issue.
Remember you can have a grand design that looks good on paper, but performs terribly in reality. On the other hand you could start coding straight away and be so swamped that your realise a road-map would have been useful.
Reading the comments on the blog site, I see that they mention that one advantage of being able to create a PDF straight from Office, as opposed to a print driver, is that it will maintain any embedded links that were in the original document. Maybe we will see a native PDF printer in Vista as well, though if Office an add extra stuff to the PDF, like relative links (for indexes, contents pages, etc) and even side-bar links, then it would certainly be a useful plus. I wonder, whether you could make it so a system wider printer driver could support all that?
Whatever the truth, one thing that really bothers me is the corporate users of Office. For example, you send them a document in PDF format and they insist on having a Word format. This is especially true for CVs.
I looked at the New York subway map and got wondering, which is your favourite transport map (from any city) in terms of readability and design?
How about buying out Apple Records and make them their record company. :)
The record labels are biting the hand that feeds them.
They bite the vendors, and they screw everyone else, including the artists and the buyers. If this is not monopoly abuse then I don't know what is. I think your average drugs dealers is a bit better than these guys - even they aren't, at least the law knows how deal with drugs dealers.
From reading the FAQ on the Blu-ray.com web site (not same as Blue-ray association) there are already players supporting Blu-ray in Japan, but we are unlikely to see them in North America until 2006.