This list is indeed very US-centric. And OK, there's nothing inherently wrong with that, being as it's a US site and everything, but there is something missing from this list.
In the UK in the late 70's and early 80's a very different computing buzz was going on, so I'd like to mention the claims of two other machines: the BBC Micro and the Sinclair ZX Spectrum.
The Spectrum was the machine (even more than the ZX80 and 81 before it) that switched lots of kids of my generation onto computing. And it's why, to this day, we have some of the best programmers, developers (and games people) in the world. It may not have had the graphics and audio power of the C64, but it took ingenuity to squeeze perfomance out of Uncle Clive's little rubber keyed wonder. A huge kitechen sink games market grew up around the Spectrum and many of us learned to program on it.
The BBC Micro was damn near ubiquitous in British schoools in the 1980's and is probably the one thing about Margaret Thatcher's time in office that she called absolutely correctly: the need to get computers into schools. Sincalir came very close to winning the contract to supply BBC-badged computers to put into our schools (as apart of an initiative to introduce home computing to the masses), but in the end Acorn (later to become ARM) got the nod. For the time, the Beeb was a pretty powerful and expandable machine, with probably the best version of BASIC on the market.
Both of these machines helped to kick start computing in the UK, but never really made it across the pond (though the Speccy was badged as a Timex sinclair and sold in the states). A whole generation of kids used the Beeb at school and came home ot a spectrum (the best seller here). Before the IBM ear, these were the machines that defined home comuting in the UK.
This is the fundamenetal problem with phonetic simplification in English. Noam Chomsky and others talk about this issue, debating whether written English is more a phonetic language or whether it shares something with ideogramatic languages like the written Chinese ones. In reality, it seems to be a mix and it has a practical knock on in the approach to teaching early years reading. In other languages (like French where the Academie Francaise was reposnsible for regularising a lot of spelling in the 17th and 18th Centuries, I believe), where there is a greater degree of regularity, phonetic spelling is not so much of a problem, but in English we would certainly lose something. And, from the examples given in the post I'm replying to, they take longer to read and are actually harder to understand. What's the point of that? (but of course, that's the point they were trying to make)
Part of the issue for me, as someone who loves words, is seeing (or not) the etymology that sits within the spelling. the given example "dictionary" in the original post, for instance: the phonetic spelling gives no clue that it related to words like dictum, dictate, edict and similar. Or that it shares common ancestry with verbs in French like dire or decir in Spanish. I think losing that would be sad, and would make understanding the English language a lot more difficult, especially for foreign speakers.
Another example: if you don't know what an iatrogenic illness is, how would you work out what it was if it was phonetically spelled? At least here you might have a clue that iatro comes from the Greek word for a doctor, so you could make a good stab at guessing that it's an illness caused by one.
What it all boils down to is this: a computer is a tool used by someone to perform or achieve some task.
To be 'literate' in the use of such a tool one must need to know how to perform the tasks for which the system is to be used and then to have some idea of what happens when it does not work as planned (including knowing who might be able to fix that problem)
The complicating factor here is that of what the task is. For those who are doing admin work, a working knowledge of the apps themselves and the general working environment (the UI, whichever OS) are essential. For developers, software aengineers and admins these skills may be more technixcally focused but equally valid. For example, at a simple level, you administer an (apache) webserver in Linux. You need to know roughly how the server and config works (the tool) and how the surrounding environment (likely to be your shell of choice) works.
As has been said, flooding people's heads with stuff they are not likely to need often enough to be helpful is not only problematic, it is counter-productive and switches them off, making sure that they don't even think about the obvious stuff anymore.
...by making a business case based on their bottom line.
That is the only language that will be understood.
From the sound of it, you're being severely overloaded; you need to force the issue some more (I've been in the same position myself and this is how I got through it). You will have to decide what your core job functions are (that you absolutely must do), then concentrate on them even if it means letting other stuff pile up undone. This would be even more justifiable if you have a job description you can refer to to back this up. If you don't have one, get one, just to confirm to you what your managers think you are doing, and to let them know what you actually are.
If people give you extra work or pile you will extra repsonsibilities without the resource to do it, get them, to tell the people whose jobs you'll have to push back. Many of the reasone IS is pushed down the list is becasaue mostly,' it just works'. What happens when it doesn't? I think you have to start being a little less conscientious, because otherwise it will make you ill. You can still be professional and rein back your work to realistic levels.
For your own benefit, keep a detailed log of where yuor time goes (if you don't already). And also include things yuo cannot do. Make estimates of the cost of this lost productivity. This should be the basis of your business case.
Someone mentioned hiring an intern: this might be nice as a short-term move but doesn't address long term structural problems your company seems unwilling to face.
If you still get no repsonse. Walk; tell them precisely why, adding that you wish them luck trying to find someone who can do your job with no training.
I may be saying nothing you don't already know; you're expreienced in the industry after all, but sometimes just looking at the obvious stuff can help. Good luck.
I have a colleague (and a good friend) who is a fairly high-profile forensice examiner and forensic computing expert. I have some knowledge of the area. When we discussed the 90-day argument that Blair put forward, his reaction was fairly clear:
In the UK, this legislation already exists, it's called the Regulation of Investigatory Powers Act 2000 (RIPA). The provisions of this Act allow designated authorities to force users to surrender encryption keys and passwords to allow filesystems and files to be decrypted.
if the eula is ridiculous, don't buy the code. buy someone else's or write your own.
I haven't seen too many over the top Eulas recently as to this issue, other than, you know, GPL and BPL, which assume no responsibility whatsoever, and strictly limit liability and warranty.
Yes, but as you yourself imply, if you don't like it, don't use the code. I'm not actually an OSS zealot and would (and do) happily use commerical software in the right circumstances, but at least the GPL is transparent about its position in the first couple of sentences of the licence (Note to US: before anyone complains about the spelling, I'm English; it's correct here). That's more than can be said for many (not all, I hasten to add) commercial EULAs
In contrast, of course, we have most commercial EULA's, which at least warrant substantial conformity to documentation, with a commitment to repair or replace or, at least, return your payments. For the most part, this is what the market really needs. They don't expect the vendor to be liable for loss of data that could be backed up, or the loss of business as a result of the failure of the software.
Well, yes. In theory. But as the original article said, this is fine for larger systems (and even then dubious if you consider the provision of software systems and their fitness for purpose in many failed public sector projects), but in the consumer market? Trying to actually enforce the terms of an EULA would be fun. Look at the hoops people who wanted refunds on unwanted copies of Windows bundled with machines had to jump through.
What people have a resonable right to expect is that the software will work as promised, and does not screw them over, even when they have taken reasonable steps to protect themselves. This last part is more rare in the consumer sector of course, but not unheard of.
And if you are right that the market prefers that, then you can of course compete with a better warranty -- in which case you will have a competitive advantage. If you are mistaken, you will lose your shirt. That is the way it works.
Unless of course there are significant barriers to entry. And in various parts of the larger computing market, there are. At that point, you have to wonder how large a competitive advantage you would need to justify entry at all.
Well, TeX is one example of "good" code. It may not be entirely error free, but for such a heavly used item, the number of real bugs found is very small. Just how many cheques has Don Knuth had to write recently?
To be honest, I don't think Bill T is saying anything remotely controversial. All you have to do is look at the ridiculous nature of some of the EULAs provided by the large software companies to see that.
One of the problems is actually a more theoretical one. Yes, there are systems that can be formally specified but in the main, conusmer systems work in hugely non-deterministic enivironments and the overhead of specifiying all of these externalities would mean that nothing would ever get written. Add to that the push by marketers to hit deadlines and the business implications of slipping and you have a recipe for, if not disaster, then certainly disquiet. Just leaving it entriely to the market is a risky business: there will always be some for whom cost is the primary driver and without wishing to broaden the base of this too widely, we all know that in wider society, the market has no sense of collective or moral repsonsibility, it just works the way it does; I make no critical judgement about that, that's the way markets work.
Free/Open Source software is not immune from these pressures but generally does not suffer, becasue deadlines are not shaped by external agaencies; code is ready when it's ready. And in that sense OpenOffice and Firefox are not bad examples of this mentality.
As software and IT professionals, we have to realise that these issues exist and, at least in some part take some repsonsibility and stopthe tail from wagging the dog
To be honest, USB devices can be pretty flaky and I might not trust them to be sufficiently robust to hold such important docs.
I would probably suggest using something designed for the rigours of mobile use, like an SD card: the bigger the better
The issue of how the data should be stored is a lttle more thorny. An encrypted filsystem might be one option, but I think I'd prefer it to be sitting on something unencrypted and then use file encryption to store the data on that fs. It then means you've got the option of using tools that are more freely available to read the file data in several enviroments: gpg for example. This isn't really a cheerleading post for gpg per se, it's just that because it's availaable cross-platform, you maximise your chances of being able to read the data back when you need it.
Yes and no. While I agree that people should know where their food really comes from (and that it involves pain for the animals), actaully getting them to do is not really practical and all boils to down to the issue of division and specialisation of labour. Now, getting people to watch it is much more feasible.
Anyway, back to the division of labour. You wouldn't be expected to build your own car or house or even make your own clothes. Some people do, but even they will still rely on sourcing components and ingredients from others. Unfortunately, the exchange of goods and services and all that goes with it is part of the deal with civilisation. Because of the way economics (particularly the consumerist flavour of the western world) "works", the whole problem of waste is barely even considered, nor are the social costs that go with it.
Personally, I think think coming down from the trees was a bad idea. Even coming out of the oceans may have been somewhat ill-advised [with apologies to DNA].
I work in an academic department where our principal teaching language has (for the previous 5 years) been Java. This has all been very well, but some of us have felt that the pace doesn't stretch the most able nough and takes too long to actually do anything useful. This is not actaully as criticism of Java itself, because I think it has a lot to recommend it and is relatively well designed.
As a result we are thinking about how this should change (not this year, but next). The important thing is to teach the concepts of programming first, so understanding variables, loops and conditions is, I think, paramount.
The issue of OO is more thorny. Many useful scripting tasks are, for example, written proceduarally, but larger applications usually beenfit from OO technques, tools and analysis. For that reason, I'd probably leave objects for a little while and get them writing smaller things that do useful stuff. Scripting is good for this because they can see the results of processing text fairly easily. I've discovered that over time, many students who have learned with Java have been almost unable to think in any other terms than OO if they don't get exposure to other technqiues quite quickly. Currently, we have a language paradigm module running in the final year of our programmes but I'm not sure if this is perhaps too late to be really useful.
Having said all of that, I would probably think about introducing programming via a language like Python. It's fairly clean in syntax, can run procedurally then have objects built on top as neccesary, encourages good style and is portable. Perl is a great language but definitely not for novices. The very strength of the language is the thing that might throw beginners: there are numerous ways to do one thing, and that might lead to confusion.
I remember reading some of Eric S Raymond's work that says that to hack well, you should know several different languages. If I recall he mentions Java, C, Perl, Lisp (for later) and touches I think on Python. As I talked around earlier, useful though Perl and C are, I wouldn't recommend them as first languages to learn with. I'd also recommend a shell language like bash or ksh for later too.
A collegaue of mine would probably also suggest you consider a language like Oberon or another of the Modula / Pascal family, because that is what they were principally designed for. They've fallen out of fashion now, but don't let fashion put you off.
"Like I said, there are a variety of ways to deal with the issue. All it takes is some imagination and willingness to invest some short-term effort and expense for long-term gain."
Absolutely, with you 100% on that one. Unfortunately, some of the sectors in question just have way too much entrenched interest and inertia. Even if you are forming alliances and collaborating with others, sometimes it could be that the cost-benefit payoff just doesn't justify the effort. But believe me, there's nothing I'd like more than to see this guy's office moved fully to open source to do all the things he wants. If he's willing to pay to do it (and work with others), so much the better.
I hope he lets us know how he gets on. I for one am really interested.
Well, no you can't migrate everything to Open Source. Yes, you could write the code, for sure, but nothing is in isolation; if you have an industry that's not interested in having its tools play nicely with others then interoperability is just not going to happen.
The thing to keep sight of here is that you are doing this for a reason. The reason, if you are running a business, is that there is some cost or benefit advantage to your doing it. If you stand to gain some advantage from it then you should do it, within ethical bounds of course.
I'm an open source enthusiast, and have spent a great deal of time evanglising it to others, but I'm also an IT professional and if I were acting as a consultant for you I'd advise you to be pragmatic.
The parent for my post is right in many ways, many problems are caused by bad design. But to that you have to add something else; bad requirements. If you don't know what you really want before you start out, any 'solution' you arrive at is likely to be fatally flawed.
First, ask yourself why you are doing this, then also ask if others share your needs: there maybe something to be gained by seeing if others do. Then think about what you need your systems to do. Look at functionality. If those functions can be perfomed by OSS, then consider them. If cost is a driver, factor that too. If you need to maintain file compatibility think about those costs. If you have staff with skills with particular packages, think about them and the cost of training them to use other systems (if indeed you can). Do you keep some efficiencies by keeping some of your existing infrastructure?
You may also need to consider that if others in the legal profession are thinking along similar lines, then strategy, rather than tactics are called for. Play the long game and try to drive
what vendors will provide by asking for it. If you need file format compatibility, then bug the vendors. If they're not willing to consider it, think about how you may share inofrmati nin an open way with others and try to form a critical mass that way. Remember how dominant WordPerfect used to be for legal work (it was v. common in the UK at least). Think why it faded, part of it was because MS provided tools for bringing in WP data into Word and the rest fell into place. Tools rise and fall, data formats are the thing to focus on. As long as you can share and preserve data, the tool is less imprtant. Let vendors know that.
To mangle a well-worn phrase: have the courrage to change what you can, the patience to accept the things you can't and the wisdom to know the difference.
Finally, it sounds as if you are really thinking about this so find a good consultant, sit down with him and work out what you really want, not just what you thinkyou want. Then see what you can gain by using OSS. Don't just do it because you think you can.
How far have Microsoft recognised that organisations in the real world use a variety of technologies and products in a heterogeneous environment? As a result, what steps are the company making to make some of its previously closed standards available in a way that others can use in a spirit of fair and open competition?
Are there any lessons that Microsoft developers have learned from the expericnces of open source development? Which ones, and how is that going to further affect the ongoing relationships that the compnay has with (primarily) developers and end users [realising of course that Windows and Linux end users are of sometimes radically different types]
I'm on a max of 4 months (in academia). Getting out of that is a real pain, although from discussions a work colleague in the same position as me had with a solicitor (who does some employment law work) suggests that having the period and actually being able to enforce much more than one month (if you're only paid a month in arrears, say) are two very different things...
"They who would give up an essential liberty for temporary security, deserve neither liberty or security"
Think about what that means. In order to, 'protect our freedom' our governments (I'm British, BTW) seem hell-bent on depriving us of the liberties they are supposedly trying to preserve.
Liberties like the right to go about your lawful business without hindrance by agencies of the state and the right not to be detained without recourse to due process or legal representation, are pretty much essential rights.
But when we live in a climate of fear, constantly stoked by those who have something to gain from it, the mob become ever easier to control and mainpulate; they will surrender to whatever measures will protect their security
Or will they? Only time will tell.
Re:Does PHP Have a Generic Database API Yet?
on
A Decade of PHP
·
· Score: 1
I think this is what an earlier post was talking about as well: a lack of consistency in the APIs.
PHP does have dbx, which is an approximation to DBI, ODBC or JDBC. I can't say I've used it becasue I do tend to stick to the pg_ and my_ libs. and (at least in 4.x, I suspect it may have changed in 5.0.x), it's not standard and has to enabled as a compile option.
Of course, part of the reason for this inconsistency is efficiency. As far as I've seen, many of these calls are generally wrappers around the system libs for those items. For example, the pg_ calls wrap libpq. It makes it fairly painless to extend the language if you do this and the code generally perfoms quite well, but it does certainly lead to some increased cognitive overhead for the developer.
I also find PHP's OO functionality somewhat idiosyncratic: then again, so is Perl's. Python is so much better there.
At the end of the day, however, PHP is designed to help you build webpages/webapps and do it quickly. And it's very good at that indeed, just like perl or python or a whole load of others.
This is pretty much half of what I think. for most users, it dosen't matter whether Apple runs PPC, Intel or an abacus; what matters is can they use the damn thing. In this sense the OS and the apps are the most important thing. If Apple do have this covered, and the Transition Kit and the noises around that suggest they're making the effort, then fine.
From a developer's point of view, this might actually help, not harm Linux. Why? Source code portability certainly helps and in some cases it's not much effort for developers to produce code that will simply compile and work on both platforms. I admit that this is mainly for server apps (like Postgres or Apache for example) and may be more problematic for apps with more dependence on UI. Even this is not a huge issue though, with bindings and toolkits (like GTK) available in a number of languages to help speed this kind of developement and give cross-platform functionality.
Apple have made some of the right noises with Open Source (there have been aberrations) and it's certainly not in their interest to stifle OSS development, because if they do, it may harm the future growth of OS X.
I'm a little sad that Apple have dropped PowerPC, but IBM simply couldn't deliver what Apple needed and so the parting of the ways had to come. The same thing happened when Apple moved from m69k to PPC and the company survived and prospered eventaully. why would this time be much different when conditions are actually more favourable for them to do so?
This is probably why the purchase will be investigated. It makes a lot of sense for Adobe to do this, especially if MS are eyeing Macromedia's products; they are simply hugely superior to anything they (MS) offer (eg DW vs FP).
The real headaches start to happen when you look at the portfolio Adobe will gain:
Shockwave/Director
Freehand v Illustrator
Fireworks v Photoshop/ImageReady
Dreamweaver vs GoLive
In these sections there are clear winners, and I think we all know which ones they would be (just thinking of market share and/or niche value, regardless of personal preferences). From an engineering view, it would be difficult to consolidate some of these items, although they could attempt to work some features in at a later point.
The main problem for Adobe is that of Flash: a de facto standard that is almost ubiquitous.
Adobe have invested a lot of time and effort in SVG (especially if you look at Illustrator and the viewers). What does that do for SVG? And how does Adobe position SVG and Flash as part of the single portfolio?
It's possible that they may go with both horses, but given that there is likely to be a great deal of rationalisation in other areas, why should this one be different? It could be that they realise there are several markets where each might fit better. Flash is great for the consumer market, for example, but I can picture a lot of very useful outflows for SVG in the corporate world, especially if tied to dynamic data and scripting. The openness of the SVG standard and its XML-ness does make life easier for developers to glue SVG to services and manipulate it. Who knows? But times are uncertain now, I think, if you use SVG.
Slashdot Mirror
This list is indeed very US-centric. And OK, there's nothing inherently wrong with that, being as it's a US site and everything, but there is something missing from this list.
In the UK in the late 70's and early 80's a very different computing buzz was going on, so I'd like to mention the claims of two other machines: the BBC Micro and the Sinclair ZX Spectrum.
The Spectrum was the machine (even more than the ZX80 and 81 before it) that switched lots of kids of my generation onto computing. And it's why, to this day, we have some of the best programmers, developers (and games people) in the world. It may not have had the graphics and audio power of the C64, but it took ingenuity to squeeze perfomance out of Uncle Clive's little rubber keyed wonder. A huge kitechen sink games market grew up around the Spectrum and many of us learned to program on it.
The BBC Micro was damn near ubiquitous in British schoools in the 1980's and is probably the one thing about Margaret Thatcher's time in office that she called absolutely correctly: the need to get computers into schools. Sincalir came very close to winning the contract to supply BBC-badged computers to put into our schools (as apart of an initiative to introduce home computing to the masses), but in the end Acorn (later to become ARM) got the nod. For the time, the Beeb was a pretty powerful and expandable machine, with probably the best version of BASIC on the market.
Both of these machines helped to kick start computing in the UK, but never really made it across the pond (though the Speccy was badged as a Timex sinclair and sold in the states). A whole generation of kids used the Beeb at school and came home ot a spectrum (the best seller here). Before the IBM ear, these were the machines that defined home comuting in the UK.
Absolutely
This is the fundamenetal problem with phonetic simplification in English. Noam Chomsky and others talk about this issue, debating whether written English is more a phonetic language or whether it shares something with ideogramatic languages like the written Chinese ones. In reality, it seems to be a mix and it has a practical knock on in the approach to teaching early years reading. In other languages (like French where the Academie Francaise was reposnsible for regularising a lot of spelling in the 17th and 18th Centuries, I believe), where there is a greater degree of regularity, phonetic spelling is not so much of a problem, but in English we would certainly lose something. And, from the examples given in the post I'm replying to, they take longer to read and are actually harder to understand. What's the point of that? (but of course, that's the point they were trying to make)
Part of the issue for me, as someone who loves words, is seeing (or not) the etymology that sits within the spelling. the given example "dictionary" in the original post, for instance: the phonetic spelling gives no clue that it related to words like dictum, dictate, edict and similar. Or that it shares common ancestry with verbs in French like dire or decir in Spanish. I think losing that would be sad, and would make understanding the English language a lot more difficult, especially for foreign speakers.
Another example: if you don't know what an iatrogenic illness is, how would you work out what it was if it was phonetically spelled? At least here you might have a clue that iatro comes from the Greek word for a doctor, so you could make a good stab at guessing that it's an illness caused by one.
I agree with much of this in principle.
What it all boils down to is this: a computer is a tool used by someone to perform or achieve some task.
To be 'literate' in the use of such a tool one must need to know how to perform the tasks for which the system is to be used and then to have some idea of what happens when it does not work as planned (including knowing who might be able to fix that problem)
The complicating factor here is that of what the task is. For those who are doing admin work, a working knowledge of the apps themselves and the general working environment (the UI, whichever OS) are essential. For developers, software aengineers and admins these skills may be more technixcally focused but equally valid. For example, at a simple level, you administer an (apache) webserver in Linux. You need to know roughly how the server and config works (the tool) and how the surrounding environment (likely to be your shell of choice) works.
As has been said, flooding people's heads with stuff they are not likely to need often enough to be helpful is not only problematic, it is counter-productive and switches them off, making sure that they don't even think about the obvious stuff anymore.
Not everyone is like us.
If you're applying for a job that you know (or discover) had a previous encumbent:
"Why did the previous postholder move on?"
...by making a business case based on their bottom line.
That is the only language that will be understood.
From the sound of it, you're being severely overloaded; you need to force the issue some more (I've been in the same position myself and this is how I got through it). You will have to decide what your core job functions are (that you absolutely must do), then concentrate on them even if it means letting other stuff pile up undone. This would be even more justifiable if you have a job description you can refer to to back this up. If you don't have one, get one, just to confirm to you what your managers think you are doing, and to let them know what you actually are.
If people give you extra work or pile you will extra repsonsibilities without the resource to do it, get them, to tell the people whose jobs you'll have to push back. Many of the reasone IS is pushed down the list is becasaue mostly,' it just works'. What happens when it doesn't? I think you have to start being a little less conscientious, because otherwise it will make you ill. You can still be professional and rein back your work to realistic levels.For your own benefit, keep a detailed log of where yuor time goes (if you don't already). And also include things yuo cannot do. Make estimates of the cost of this lost productivity. This should be the basis of your business case.
Someone mentioned hiring an intern: this might be nice as a short-term move but doesn't address long term structural problems your company seems unwilling to face.
If you still get no repsonse. Walk; tell them precisely why, adding that you wish them luck trying to find someone who can do your job with no training.
I may be saying nothing you don't already know; you're expreienced in the industry after all, but sometimes just looking at the obvious stuff can help. Good luck.
I have a colleague (and a good friend) who is a fairly high-profile forensice examiner and forensic computing expert. I have some knowledge of the area. When we discussed the 90-day argument that Blair put forward, his reaction was fairly clear:
In the UK, this legislation already exists, it's called the Regulation of Investigatory Powers Act 2000 (RIPA). The provisions of this Act allow designated authorities to force users to surrender encryption keys and passwords to allow filesystems and files to be decrypted.
But in the longer term of course, even the cheap but skilled Indians will demand more money. Where will the corporations save money then?
Just a couple of points:
Yes, but as you yourself imply, if you don't like it, don't use the code. I'm not actually an OSS zealot and would (and do) happily use commerical software in the right circumstances, but at least the GPL is transparent about its position in the first couple of sentences of the licence (Note to US: before anyone complains about the spelling, I'm English; it's correct here). That's more than can be said for many (not all, I hasten to add) commercial EULAs
Well, yes. In theory. But as the original article said, this is fine for larger systems (and even then dubious if you consider the provision of software systems and their fitness for purpose in many failed public sector projects), but in the consumer market? Trying to actually enforce the terms of an EULA would be fun. Look at the hoops people who wanted refunds on unwanted copies of Windows bundled with machines had to jump through.
What people have a resonable right to expect is that the software will work as promised, and does not screw them over, even when they have taken reasonable steps to protect themselves. This last part is more rare in the consumer sector of course, but not unheard of.
Unless of course there are significant barriers to entry. And in various parts of the larger computing market, there are. At that point, you have to wonder how large a competitive advantage you would need to justify entry at all.
Well, TeX is one example of "good" code. It may not be entirely error free, but for such a heavly used item, the number of real bugs found is very small. Just how many cheques has Don Knuth had to write recently?
To be honest, I don't think Bill T is saying anything remotely controversial. All you have to do is look at the ridiculous nature of some of the EULAs provided by the large software companies to see that.
One of the problems is actually a more theoretical one. Yes, there are systems that can be formally specified but in the main, conusmer systems work in hugely non-deterministic enivironments and the overhead of specifiying all of these externalities would mean that nothing would ever get written. Add to that the push by marketers to hit deadlines and the business implications of slipping and you have a recipe for, if not disaster, then certainly disquiet. Just leaving it entriely to the market is a risky business: there will always be some for whom cost is the primary driver and without wishing to broaden the base of this too widely, we all know that in wider society, the market has no sense of collective or moral repsonsibility, it just works the way it does; I make no critical judgement about that, that's the way markets work.
Free/Open Source software is not immune from these pressures but generally does not suffer, becasue deadlines are not shaped by external agaencies; code is ready when it's ready. And in that sense OpenOffice and Firefox are not bad examples of this mentality.
As software and IT professionals, we have to realise that these issues exist and, at least in some part take some repsonsibility and stopthe tail from wagging the dog
To be honest, USB devices can be pretty flaky and I might not trust them to be sufficiently robust to hold such important docs.
I would probably suggest using something designed for the rigours of mobile use, like an SD card: the bigger the better
The issue of how the data should be stored is a lttle more thorny. An encrypted filsystem might be one option, but I think I'd prefer it to be sitting on something unencrypted and then use file encryption to store the data on that fs. It then means you've got the option of using tools that are more freely available to read the file data in several enviroments: gpg for example. This isn't really a cheerleading post for gpg per se, it's just that because it's availaable cross-platform, you maximise your chances of being able to read the data back when you need it.
Yes and no. While I agree that people should know where their food really comes from (and that it involves pain for the animals), actaully getting them to do is not really practical and all boils to down to the issue of division and specialisation of labour. Now, getting people to watch it is much more feasible.
Anyway, back to the division of labour. You wouldn't be expected to build your own car or house or even make your own clothes. Some people do, but even they will still rely on sourcing components and ingredients from others. Unfortunately, the exchange of goods and services and all that goes with it is part of the deal with civilisation. Because of the way economics (particularly the consumerist flavour of the western world) "works", the whole problem of waste is barely even considered, nor are the social costs that go with it.
Personally, I think think coming down from the trees was a bad idea. Even coming out of the oceans may have been somewhat ill-advised [with apologies to DNA].
I work in an academic department where our principal teaching language has (for the previous 5 years) been Java. This has all been very well, but some of us have felt that the pace doesn't stretch the most able nough and takes too long to actually do anything useful. This is not actaully as criticism of Java itself, because I think it has a lot to recommend it and is relatively well designed.
As a result we are thinking about how this should change (not this year, but next). The important thing is to teach the concepts of programming first, so understanding variables, loops and conditions is, I think, paramount.
The issue of OO is more thorny. Many useful scripting tasks are, for example, written proceduarally, but larger applications usually beenfit from OO technques, tools and analysis. For that reason, I'd probably leave objects for a little while and get them writing smaller things that do useful stuff. Scripting is good for this because they can see the results of processing text fairly easily. I've discovered that over time, many students who have learned with Java have been almost unable to think in any other terms than OO if they don't get exposure to other technqiues quite quickly. Currently, we have a language paradigm module running in the final year of our programmes but I'm not sure if this is perhaps too late to be really useful.
Having said all of that, I would probably think about introducing programming via a language like Python. It's fairly clean in syntax, can run procedurally then have objects built on top as neccesary, encourages good style and is portable. Perl is a great language but definitely not for novices. The very strength of the language is the thing that might throw beginners: there are numerous ways to do one thing, and that might lead to confusion.
I remember reading some of Eric S Raymond's work that says that to hack well, you should know several different languages. If I recall he mentions Java, C, Perl, Lisp (for later) and touches I think on Python. As I talked around earlier, useful though Perl and C are, I wouldn't recommend them as first languages to learn with. I'd also recommend a shell language like bash or ksh for later too.
A collegaue of mine would probably also suggest you consider a language like Oberon or another of the Modula / Pascal family, because that is what they were principally designed for. They've fallen out of fashion now, but don't let fashion put you off.
Absolutely, with you 100% on that one. Unfortunately, some of the sectors in question just have way too much entrenched interest and inertia. Even if you are forming alliances and collaborating with others, sometimes it could be that the cost-benefit payoff just doesn't justify the effort. But believe me, there's nothing I'd like more than to see this guy's office moved fully to open source to do all the things he wants. If he's willing to pay to do it (and work with others), so much the better.
I hope he lets us know how he gets on. I for one am really interested.
Well, no you can't migrate everything to Open Source. Yes, you could write the code, for sure, but nothing is in isolation; if you have an industry that's not interested in having its tools play nicely with others then interoperability is just not going to happen.
The thing to keep sight of here is that you are doing this for a reason. The reason, if you are running a business, is that there is some cost or benefit advantage to your doing it. If you stand to gain some advantage from it then you should do it, within ethical bounds of course.
I'm an open source enthusiast, and have spent a great deal of time evanglising it to others, but I'm also an IT professional and if I were acting as a consultant for you I'd advise you to be pragmatic.
The parent for my post is right in many ways, many problems are caused by bad design. But to that you have to add something else; bad requirements. If you don't know what you really want before you start out, any 'solution' you arrive at is likely to be fatally flawed.
First, ask yourself why you are doing this, then also ask if others share your needs: there maybe something to be gained by seeing if others do. Then think about what you need your systems to do. Look at functionality. If those functions can be perfomed by OSS, then consider them. If cost is a driver, factor that too. If you need to maintain file compatibility think about those costs. If you have staff with skills with particular packages, think about them and the cost of training them to use other systems (if indeed you can). Do you keep some efficiencies by keeping some of your existing infrastructure?
You may also need to consider that if others in the legal profession are thinking along similar lines, then strategy, rather than tactics are called for. Play the long game and try to drive what vendors will provide by asking for it. If you need file format compatibility, then bug the vendors. If they're not willing to consider it, think about how you may share inofrmati nin an open way with others and try to form a critical mass that way. Remember how dominant WordPerfect used to be for legal work (it was v. common in the UK at least). Think why it faded, part of it was because MS provided tools for bringing in WP data into Word and the rest fell into place. Tools rise and fall, data formats are the thing to focus on. As long as you can share and preserve data, the tool is less imprtant. Let vendors know that.
To mangle a well-worn phrase: have the courrage to change what you can, the patience to accept the things you can't and the wisdom to know the difference.
Finally, it sounds as if you are really thinking about this so find a good consultant, sit down with him and work out what you really want, not just what you thinkyou want. Then see what you can gain by using OSS. Don't just do it because you think you can.
How far have Microsoft recognised that organisations in the real world use a variety of technologies and products in a heterogeneous environment? As a result, what steps are the company making to make some of its previously closed standards available in a way that others can use in a spirit of fair and open competition?
Are there any lessons that Microsoft developers have learned from the expericnces of open source development? Which ones, and how is that going to further affect the ongoing relationships that the compnay has with (primarily) developers and end users [realising of course that Windows and Linux end users are of sometimes radically different types]
If the image is two years out of date, then isn't this the perfect piece of disinformation to confound any prospective terrorist?
You didn't work for a company called Tradezone did you? Because that sounds really familiar!
3 months. Pah!
I'm on a max of 4 months (in academia). Getting out of that is a real pain, although from discussions a work colleague in the same position as me had with a solicitor (who does some employment law work) suggests that having the period and actually being able to enforce much more than one month (if you're only paid a month in arrears, say) are two very different things...
Benjamin Franklin:
Think about what that means. In order to, 'protect our freedom' our governments (I'm British, BTW) seem hell-bent on depriving us of the liberties they are supposedly trying to preserve.
Liberties like the right to go about your lawful business without hindrance by agencies of the state and the right not to be detained without recourse to due process or legal representation, are pretty much essential rights.
But when we live in a climate of fear, constantly stoked by those who have something to gain from it, the mob become ever easier to control and mainpulate; they will surrender to whatever measures will protect their security
Or will they? Only time will tell.
I think this is what an earlier post was talking about as well: a lack of consistency in the APIs. PHP does have dbx, which is an approximation to DBI, ODBC or JDBC. I can't say I've used it becasue I do tend to stick to the pg_ and my_ libs. and (at least in 4.x, I suspect it may have changed in 5.0.x), it's not standard and has to enabled as a compile option.
Of course, part of the reason for this inconsistency is efficiency. As far as I've seen, many of these calls are generally wrappers around the system libs for those items. For example, the pg_ calls wrap libpq. It makes it fairly painless to extend the language if you do this and the code generally perfoms quite well, but it does certainly lead to some increased cognitive overhead for the developer.
I also find PHP's OO functionality somewhat idiosyncratic: then again, so is Perl's. Python is so much better there.
At the end of the day, however, PHP is designed to help you build webpages/webapps and do it quickly. And it's very good at that indeed, just like perl or python or a whole load of others.
Yes, but (l)users DO want to be able to look at their favourite web sites without the browser making a mess of it.
If they can't do that, they won't use it.
Pretty much the same thing, if you define a terrorist as,
Just because it's done by a government doesn't mean it's not terrorism.
This is pretty much half of what I think. for most users, it dosen't matter whether Apple runs PPC, Intel or an abacus; what matters is can they use the damn thing. In this sense the OS and the apps are the most important thing. If Apple do have this covered, and the Transition Kit and the noises around that suggest they're making the effort, then fine.
From a developer's point of view, this might actually help, not harm Linux. Why? Source code portability certainly helps and in some cases it's not much effort for developers to produce code that will simply compile and work on both platforms. I admit that this is mainly for server apps (like Postgres or Apache for example) and may be more problematic for apps with more dependence on UI. Even this is not a huge issue though, with bindings and toolkits (like GTK) available in a number of languages to help speed this kind of developement and give cross-platform functionality.
Apple have made some of the right noises with Open Source (there have been aberrations) and it's certainly not in their interest to stifle OSS development, because if they do, it may harm the future growth of OS X.
I'm a little sad that Apple have dropped PowerPC, but IBM simply couldn't deliver what Apple needed and so the parting of the ways had to come. The same thing happened when Apple moved from m69k to PPC and the company survived and prospered eventaully. why would this time be much different when conditions are actually more favourable for them to do so?
This is probably why the purchase will be investigated. It makes a lot of sense for Adobe to do this, especially if MS are eyeing Macromedia's products; they are simply hugely superior to anything they (MS) offer (eg DW vs FP).
The real headaches start to happen when you look at the portfolio Adobe will gain:
In these sections there are clear winners, and I think we all know which ones they would be (just thinking of market share and/or niche value, regardless of personal preferences). From an engineering view, it would be difficult to consolidate some of these items, although they could attempt to work some features in at a later point.
The main problem for Adobe is that of Flash: a de facto standard that is almost ubiquitous.
Adobe have invested a lot of time and effort in SVG (especially if you look at Illustrator and the viewers). What does that do for SVG? And how does Adobe position SVG and Flash as part of the single portfolio?
It's possible that they may go with both horses, but given that there is likely to be a great deal of rationalisation in other areas, why should this one be different? It could be that they realise there are several markets where each might fit better. Flash is great for the consumer market, for example, but I can picture a lot of very useful outflows for SVG in the corporate world, especially if tied to dynamic data and scripting. The openness of the SVG standard and its XML-ness does make life easier for developers to glue SVG to services and manipulate it. Who knows? But times are uncertain now, I think, if you use SVG.