For the record, my comment wasn't primarily driven by the hammer instruction set (which I've only briefly investigated - I was aware that it had both 64 and 32 bit instructions) but rather by my assumptions about the majority of current software has been designed with a view to being run on 32 bit platforms.
In my opinion, in order for 64 bit architectures to reach full potential, a change of software structure is required.
Firstly, let me clarify - I am not worried about a handful of linked lists, but rather the more general assumption that we can assume no locality of reference when we implement data structures.
Yes, we can argue that RAM is cheap... but as you eloquently point out, buying more RAM doesn't overcome all of the implications. Other bottlenecks exist, and I can think of several:
Level 1 and Level 2 cache (as you suggest)
Network packets (when transmitting pointers as tokens, for example.) - this one even has a double whammy if you cause packets to exceed the frame size for your network protocol.
Hard Disk IO and cache issues are affected by larger data structures should applications store in native (or near-native) formats.
my little site will finally be able to handle a good slashdotting with 16GB of DDR333
Hmmm. I'm probably more interested than most in the prospects of large address spaces, however I don't imagine typical web sites are where this technology will be best exploited. Think seriously, moving to 8 byte addresses has the following effects:
Massively expanding address space and hence (for the first time - IMHO) making the holy grail of direct manipulation of persistent data structures a realistic proposition.
Expanding the size of today's simple data structures. Consider, for example, a simple bi-directional linked list of 32-bit integers using a forwards and backwards pointer. A 32 bit arch has a 200% overhead, but 64 bit ach has 400% which should somewhat diminish expectations for magical performance!
Don't get me wrong. I think 64 bit is likely to be at least as important a step as 32 bit was c. 20 years ago, however I don't expect more than a small niche for such systems until resource allocation is re-thought.
I'd rather be in that room making my (admittedly open-ended) statement than trying to justify some half-baked anally retentive series of burdensome constraints, which seemed appropriate for some completely dissimilar project.
Good code, like good art is very hard to define, though like with art, a group of professionals are likely to be able to distinguish wheat from chaff. In a simplistic manner, you can think of art as "good" if the target audience appreciate it. Similarly, I consider code and specifications "good" if the target audience are of the opinion that they are clear and concise. I personally don't think there is a recipe one can blindly apply to all projects. The game should be "does this change make the source more or less 'clear and compact'?" The trade off between adding comments (increasing verbosity) and eliminating them (increasing brevity) can only be made when you understand the target audience - i.e. everyone who will ever want to read the source!
My vote is that everyone should use a CRC (Class Responsibility and Collaboration) style (wherever sensible). I want to know why a class exists and where it is to be used and what is its purpose - down to the level of detail of behaviours of individual methods. Thereafter I prefer to see concise and compact code and shy away from comments reading as if a chatty soliloquy (which often bears little or no correlation to the code - especially after it has been "maintained" by a few people!)
Coding standards, to me however, seem to be quite a red herring... all code should be correct, coherent, compact and with a similarly crystal-clear specification. Most "coding standards" I've encountered have concentrated on fine-grained stylistic issues while ignoring the wider goal of concise clarity.
In his book George Soros on Globalization, the billionnaire asks for institutional reforms to address some of the many political concerns globalism raises:
l. Contain the instability of financial markets.
So... am I expected to believe that Mr Soros (of UK "Black Wednesday", Sept 1992 fame) is actually in favour of stabilising financial markets?
If that review was glowing... I'd hate to receive a scathing one!
The sad fact is that office applications are the most vital component of a business system. If someone intends to take the office application monopoly from MS, it is insufficient to be "almost as good" some of the time... there needs to be some dramatic benefit. I hope this will eventually arise in the form of a suite of productivity programs offering all the desirable features of recent MS Office suites but also offering a level of guarantee that the software will not become obsolete due to future enhancement of others' systems.
Competitors need to look at producing a reliable, functional, easy to use, feature rich alternative - as far as I'm aware that hasn't happened as yet.
Why not use a handful of these cheap and cheerful servers as your backup facility? IMHO, the issue of reduced reliability is outweighed by the following factors:
For many deployments, it is important to minimise down time - the cheap TB server can easily be switched into service for an emergency situation - this is less easy if you have backup tape.
The incompetence problem is reduced by fully automatic systems - hence reducing the risk that someone may "forget to put the tape in" the night before the disaster.
Remote physical locations can be used for backup servers like this - hence reducing the likelihood that the off-site tape (containing the only copy of the data after the fire) happens to have been buried by your neighbour's dog.
Lets face it... the days of tape backups are (hopefully) numbered.
So... would I be right in thinking that the "Wayback Machine" is an (admittedly large scale) exercise in network database programming (of the style popular pre Codd and his relational model?) I am tempted to question if this is indeed the biggest database ever built - I suppose it depends upon definitions - but to my mind a database should be general purpose... whereas it appears to me that this project is basically a large-scale single index.
I also wonder if it would be appropriate to call this the largest project of it's kind - for example - while Google stores less data, I suspect it supports a higher query rate... how exactly do you intend to measure scale... if it is in terms of computing power is it relevant that Google already have thousands of Linux server nodes?
That said - I think it is an exciting project in its own right. I hope and expect this offering to become a significant information resource in years to come.
I hope Alan isn't cutting off his nose to spite his face - but he seems a bright bloke - so I hope he has other options planned out.
From a personal perspective - I'd be reluctant to work for AOL/TW as well - but my reasons are probably different. In my limited experience I can't trust AOL - and aim never to help fill their coffers since they denied fraudulently drawing funds from my bank account in 1994. It was a small sum (£5 twice) but I did notice and made no progress trying to stop them drawing forcing me to close the account. I have nothing but contempt for AOL's business practices, and actively aim to direct others towards their competitors. I realise that my losses were trivial - but I find their ethics appalling.
I'm pleased to see someone (hopefully with other irons in the fire) refuse to assist their questionable practices.
> > ZeoSync expects to overcome the existing temporal restraints of its technology
> Ah... So even if it's not outright bullshit, it's too slow to use?
No, my friend - you are missing the whole point. ZeoSync HAVE succeeded (in a limited sense.) You see, in order to achieve implausible compression rates on random data - all you need to do is overcome a few temporal issues - follow this line of thinking...
1) Each implementation of the compression algorithm will only be applied to (a relatively small finite number of) finite sequences of bits.
2) Encode exactly these sequences in the compression tool.
3) Astonishing compression is achieved - only a small ordinal need be stored to represent each compressed result.
So your data will always be small, but your compression program will grow rather quickly!
So, let me get this right, only businesses have information they want to remain secure? I don't think so. Amusingly, it seems that it would be unacceptable to use MS.Net with at-home broadband if the application you were using happened to have been implemented using call backs and had "security" turned on. Fantastic... in any case, unless all home traffic is being intercepted and understood, it would be impossible to enforce a 'NO VPN' rule - that is unless they refine their ideas.
To my mind, all that should be required of software is a formal (or at least rigorous) specification of the external interfaces, and the protocols which they support. If MS were required to provide a full specification of their products, then there should be no need for open Windows source. To my mind, it would then be reasonable to expect that any product which is adheres to this specification should remain compatible with MS mainstream. This would have two desirable consequences:
Buggy software could be irrefutably demonstrated. Customers demonstrating flaws could expect either a resolution within some reasonable time frame, or financial compensation for migration to a system without the flaw.
The quality of third party components could be evaluated relative to the specification of interfaces they claim to support.
The obvious issue with this is "who could declare a specification to be rigorous?" Do you feel you have the correct background for this task, or do you see a better way to ensure MS (or any other software vendor for this matter) respects their obligations?
I agree that the whole refinement of specifications idea is fantastically straightforward in principle, but that in practice this is not necessarily so. Practical specifications are frequently hopelessly woolly bloated mammoths, and far too frequently (in my experience at least) require provably impossible behaviours of systems - which is amusing until you realise you've wasted days concerning yourself with an impossible aspect of the design about which nobody cares!
My argument is that programmers must behave primarily as artists not as scientists. This doesn't mean I don't think that formal techniques and tools are anything other than invaluable. On the contrary, I believe that exactly these techniques set software apart from other art forms. Software is unique in that it should be possible to evaluate software objectively, however, until computer professionals agree how comparisons should be made, I feel we are doomed to remain in the dark ages with a prevalence of shoddy projects plagued by avoidable bugs.
The specification and design of software, and in this I also refer to detailed refinement of the design until you arrive at an executable product is an art, not a science. If it were a science for which we can define a satisfactory set of rules to ensure a quality product emerges, then I'd write a program to write programs and we'd all become redundant. Reductio ad absurdium!
As the design aspect of software - every time a choice has to be made to move from one high level idea to a concrete implementation - then this requires a subjective decision. If we want to improve software quality, then we need to take an entirely different approach. We still need the coding artists, in order to come up with ideas, and we need the specification artists to capture ill-defined scenarios to the best of their ability. The interesting stage comes thereafter... once we've arrived at a specification and implementation. The specification can be assessed depending upon whether a system meeting this specification performs well once deployed. The software can be assessed upon several criteria - significantly including:
1) Satisfaction of the specification that came before (should be 100%)
2) Resources consumed to realise each interaction (the less the better) - Code side; memory use; disk reads; wall clock time required; interactive response etc.
3) Availability of formal proofs that a specification is satisfied.
4) Burden of assumptions made about any underlying technology, and failure model assumed to cope with unexpected events and failures.
What we need is a robust way to specify requirements; and indisputable ways to show when an implementation doesn't meet a specification - and a strategy by which alternate implementations of small components can be compared in the context of the project specification.
While I find the STL invaluable, my experiences with it under VC6 leave me less than impressed. I've encountered problems with relation to multiple threads, which proved most unpleasant. While, as anyone who has used the STL for more than "hello world" will know, the STL is not thread safe. The problem arises in determining the acceptable ways in which an STL object can be used in a multithreaded application. At first I assumed that it was acceptable to wrapper access to each object with a critical section, but came to realise after several hours that this was inadequate for MSVC 6 STL in light of certain functions depending upon the use of static internal attributes... hence requiring me to impose a global scope critical section whenever I accessed any of my container objects derived from STL bases. It is also important to realise that the signatures to certain methods are not the same as in other implementations... I particularly recall differences between MS's erase() and the status quo suggested by platform independent STL documentation.
Some "bugs" are reported by Dinkumware, who purport to have written the VC6 STL, but also offer to sell a "better version". I also remember Service pack 4 breaking the STL, which was reverted in service pack 5. I have had less problems with the STLport implementation, but any developer considering a design based on multiple threads and the standard MS VC6 STL should beware!
I use a conventional modem at home out of choice - despite the availability of broadband in my neighbourhood - I just don't see a justification for my home use at the moment. Despite being a continual computer user (and finding broadband at work invaluable) I don't think I'd make sufficient use to make aggravation of an installation worthwhile. Sure things may change if I start working from home, but with a typical daily transfer of say 2MB (little of which I interactively wait for - think email and downloaded software packages.) why do I need this whiz-bang high capacity? I would like to have a personal server on which I can securely stash all the data which I don't carry with me on my laptop, for which I would need an always on connection, but I don't see ADSL like services as the solution there - I'd want something symmetric - being related to Scruge however, I won't even consider a leased line:-)
Broadband will take off when it is cheaper to have broadband for a month than pay for a dialup bill... We need mass take-up for broadband to really take off, and that means making it a cost effective option for occasional users who currently enjoy their hour online each month for at most a few pence. Maybe the answer to this is to start charging by the MB for transfers? I suppose that would mean people would need to run a secure OS too to avoid extortionate bills:-)
From my perspective, while obscenely large limits on file system sizes are no bad thing, I'm more interested by the prospect for scalability in the context of realistic problems. I see much larger challenges in establishing systems to maximally exploit locality of reference. I'd also like to see memory mapped IO extended to allow direct use to be made of entire large scale disks in a single address space using a VM-like strategy... but I guess this will only be deemed practicable once we're all using 64 bit processors. Are there any projects to approximate this on 32 bit architectures?
In my experience, the ability to give an estimate as to a timescale is extremely useful when it comes to planning. When a knowledgeable person asks how long a problem will take, I'm taken to one of these options:
I've no-idea - it will take X days to 'nail down' what we want before I can give a more accurate answer... and this assumes everyone else can answer my non-technical questions immediately.
This is going to be hard... Think in terms of several months/weeks or more for a first version, which probably won't be all that you're looking for.
This is not really hard - just tedious - it requires X lines of code to be (trivially) altered which will probably take about X hours.
This is easy - come back in a few hours - it will be ready then.
I know less about this that Mr/Ms Y - so I suggest you ask them.
I have found I've got better at my estimates as I become more experienced... I've also learned that using terminology like "a few..." is very useful, as it leaves a reasonable margin for error. It feels honest too:-) In many situations these rough guesses are just what is needed in order to start strategic plans. Even wildly inaccurate estimates are useful when you need to prioritise the order in which tasks are tackled.
Having first heard about FPGA tech a few years ago, and realising that while it presented some interesting "tricky" problems, I completely failed to think of one application proving both interesting and vaguely plausible for which an FPGA would be the best practical "way to go". Recently I had several ideas - for which only IO bandwidth seemed an unavoidable problem. Is there someone who can comment on the feasibility of implementing:-
A bit addressable cache... By this I mean accepting that main store is addressed typically by words of length 1,2,4 or 8 octets, and words can be read/written at word boundaries... can I use FPGA technology to allow me to write the first n bits from my register to an arbitrary bit offset in main store in a single processor cycle? This would be a boon for processing data structures for transmission/storage. Yes, storage and bandwidth are cheap, but in applications where serialisation is demanded, efficient and flexible data structures are very important for scalability. I see this becoming more of an issue as processor word sizes increase.
Is it yet feasible to implement an AVL (red-black or similar) tree in hardware? I'd love to be able to consider sets a natively supported data structure:-)
At work we recently had a discussion about the current state of viruses - and our consensus was that most were thankfully reasonably benign - in real terms they were simple to detect and eradicate. I for one hope we don't return to the old-school where executables are modified and viruses interact with the OS at the lowest levels - gradually damaging data in order to ensure that errors are propagated thorough grandfather-father-son backups. This sort of low-level virus was a serious problem in days of yore... and can you imagine trying to detect a binary level real-time encrypted/decrypted monster for which there is no clear signature. What a nightmare that would be - at least right now the most prevalent damage seems to be to pride rather than mission critical data.
I'd postulate that without this flurry of viruses that have plagued Windows of late, the masses would still be completely ignorant of security issues. By causing embarrassment, affected users are likely to remember their mistake and avoid future repeats - not that I think virus writing is in any way justifiable. Sure - releasing exploit information to live systems is dangerous - expanding the availability of this information certainly damages the security of the systems in question. However, we all know that the real problems lie with the abominable quality of MS closed source systems.
There is a solution - to both this and the problematic anti-competitive claims - we need legislation. We must require all organisations using computers to manage personal information (in the UK exactly that information which is covered by the DP act) to only use suppliers who fully disclose all interfaces to their systems for public inspection. I don't believe that we should require Open Source (although that certainly meets the requirements of specification) - but I believe that a supplier who falsely, or incompletely documents a formal specification should be held liable without limit for any consequential damage which can be attributed to any discrepancy between the system and it's specification. Simple, effective and our only defence against "evil terrorists" otherwise minority groups with selfish agendas will surely wreak havoc be on the free and democratic world. Start the lobbying!
My take on this question is that I'm sure that there is loads of fun work out there - although in the environment of limited funding changing jobs should not be taken lightly. However, for myself, a fun job is one where I'm given sufficient freedom and resources to make me productive. If you can solve problems you will be a valued employee and even when jobs are scarce - you will find work with any organisation that feels they can trust you.
That said, I enjoy solving non-obvious problems, love technology and have been obsessed by software for over a decade. I hate computer games, love good food and think that a friendly, light and well-equipped workplace can't be over valued. I'm very aware that jobs I find interesting are "dangerous" but this is because I like adventurous ventures. This is why I do work for others. I've been asked to recommend others for jobs I'd find interesting, but I've had to explain that everyone I know who is up to the job is in well-paid stable employment - good people are still hard to find.
I hope my post was "Funny,3" because there was no "Ironic" tag available to moderators...
It was a serious remark - if there was a way to have people who send me email charged, I would use it... assuming this did not make it any more time consuming or difficult to contact me. If every mail cost the same as a cheap phone call, then I'd be happy. I can't think of anyone from whom I would like to hear being unwilling to bear such a cost, but I would imagine this eliminating the vast majority of my unwelcome mail. In order for this idea to be a success, then user authenticity must be addressed first enabling me to choose not to receive email from accounts without a verified real-world identity.
All we all need is Microsoft to introduce a new email variant where the sending party is charged for each email sent, hence diminishing the wish of users to impose unnecessary noise.
In the UK we have "The data protection act" which allows anyone over the age of 18 to demand a printed copy of all personal information stored about them online (and now, I understand, offline, for example printed) records. The glitch is that a "reasonable search fee" is acceptable (about which I'm annoyed) but the company is required to amend any inaccurate or unnecessary records.
Doesn't America have one of these? Has anyone actually challenged MS to provide a printed breakdown?
Slashdot Mirror
In my opinion, in order for 64 bit architectures to reach full potential, a change of software structure is required.
Yes, we can argue that RAM is cheap... but as you eloquently point out, buying more RAM doesn't overcome all of the implications. Other bottlenecks exist, and I can think of several:
And, I'm sure that there are more:-)
Hmmm. I'm probably more interested than most in the prospects of large address spaces, however I don't imagine typical web sites are where this technology will be best exploited. Think seriously, moving to 8 byte addresses has the following effects:
- Massively expanding address space and hence (for the first time - IMHO) making the holy grail of direct manipulation of persistent data structures a realistic proposition.
- Expanding the size of today's simple data structures. Consider, for example, a simple bi-directional linked list of 32-bit integers using a forwards and backwards pointer. A 32 bit arch has a 200% overhead, but 64 bit ach has 400% which should somewhat diminish expectations for magical performance!
Don't get me wrong. I think 64 bit is likely to be at least as important a step as 32 bit was c. 20 years ago, however I don't expect more than a small niche for such systems until resource allocation is re-thought.I'd rather be in that room making my (admittedly open-ended) statement than trying to justify some half-baked anally retentive series of burdensome constraints, which seemed appropriate for some completely dissimilar project.
Good code, like good art is very hard to define, though like with art, a group of professionals are likely to be able to distinguish wheat from chaff. In a simplistic manner, you can think of art as "good" if the target audience appreciate it. Similarly, I consider code and specifications "good" if the target audience are of the opinion that they are clear and concise. I personally don't think there is a recipe one can blindly apply to all projects. The game should be "does this change make the source more or less 'clear and compact'?" The trade off between adding comments (increasing verbosity) and eliminating them (increasing brevity) can only be made when you understand the target audience - i.e. everyone who will ever want to read the source!
My vote is that everyone should use a CRC (Class Responsibility and Collaboration) style (wherever sensible). I want to know why a class exists and where it is to be used and what is its purpose - down to the level of detail of behaviours of individual methods. Thereafter I prefer to see concise and compact code and shy away from comments reading as if a chatty soliloquy (which often bears little or no correlation to the code - especially after it has been "maintained" by a few people!)
Coding standards, to me however, seem to be quite a red herring... all code should be correct, coherent, compact and with a similarly crystal-clear specification. Most "coding standards" I've encountered have concentrated on fine-grained stylistic issues while ignoring the wider goal of concise clarity.
l. Contain the instability of financial markets.
So... am I expected to believe that Mr Soros (of UK "Black Wednesday", Sept 1992 fame) is actually in favour of stabilising financial markets?
If that review was glowing... I'd hate to receive a scathing one!
The sad fact is that office applications are the most vital component of a business system. If someone intends to take the office application monopoly from MS, it is insufficient to be "almost as good" some of the time... there needs to be some dramatic benefit. I hope this will eventually arise in the form of a suite of productivity programs offering all the desirable features of recent MS Office suites but also offering a level of guarantee that the software will not become obsolete due to future enhancement of others' systems.
Competitors need to look at producing a reliable, functional, easy to use, feature rich alternative - as far as I'm aware that hasn't happened as yet.
Why not use a handful of these cheap and cheerful servers as your backup facility? IMHO, the issue of reduced reliability is outweighed by the following factors:
For many deployments, it is important to minimise down time - the cheap TB server can easily be switched into service for an emergency situation - this is less easy if you have backup tape.
The incompetence problem is reduced by fully automatic systems - hence reducing the risk that someone may "forget to put the tape in" the night before the disaster.
Remote physical locations can be used for backup servers like this - hence reducing the likelihood that the off-site tape (containing the only copy of the data after the fire) happens to have been buried by your neighbour's dog.
Lets face it... the days of tape backups are (hopefully) numbered.
So... would I be right in thinking that the "Wayback Machine" is an (admittedly large scale) exercise in network database programming (of the style popular pre Codd and his relational model?) I am tempted to question if this is indeed the biggest database ever built - I suppose it depends upon definitions - but to my mind a database should be general purpose... whereas it appears to me that this project is basically a large-scale single index.
I also wonder if it would be appropriate to call this the largest project of it's kind - for example - while Google stores less data, I suspect it supports a higher query rate... how exactly do you intend to measure scale... if it is in terms of computing power is it relevant that Google already have thousands of Linux server nodes?
That said - I think it is an exciting project in its own right. I hope and expect this offering to become a significant information resource in years to come.
I hope Alan isn't cutting off his nose to spite his face - but he seems a bright bloke - so I hope he has other options planned out.
From a personal perspective - I'd be reluctant to work for AOL/TW as well - but my reasons are probably different. In my limited experience I can't trust AOL - and aim never to help fill their coffers since they denied fraudulently drawing funds from my bank account in 1994. It was a small sum (£5 twice) but I did notice and made no progress trying to stop them drawing forcing me to close the account. I have nothing but contempt for AOL's business practices, and actively aim to direct others towards their competitors. I realise that my losses were trivial - but I find their ethics appalling.
I'm pleased to see someone (hopefully with other irons in the fire) refuse to assist their questionable practices.
Steve
> > ZeoSync expects to overcome the existing temporal restraints of its technology
> Ah... So even if it's not outright bullshit, it's too slow to use?
No, my friend - you are missing the whole point. ZeoSync HAVE succeeded (in a limited sense.) You see, in order to achieve implausible compression rates on random data - all you need to do is overcome a few temporal issues - follow this line of thinking...
1) Each implementation of the compression algorithm will only be applied to (a relatively small finite number of) finite sequences of bits.
2) Encode exactly these sequences in the compression tool.
3) Astonishing compression is achieved - only a small ordinal need be stored to represent each compressed result.
So your data will always be small, but your compression program will grow rather quickly!
Puzzle solved.
So, let me get this right, only businesses have information they want to remain secure? I don't think so. Amusingly, it seems that it would be unacceptable to use MS .Net with at-home broadband if the application you were using happened to have been implemented using call backs and had "security" turned on. Fantastic... in any case, unless all home traffic is being intercepted and understood, it would be impossible to enforce a 'NO VPN' rule - that is unless they refine their ideas.
- Buggy software could be irrefutably demonstrated. Customers demonstrating flaws could expect either a resolution within some reasonable time frame, or financial compensation for migration to a system without the flaw.
- The quality of third party components could be evaluated relative to the specification of interfaces they claim to support.
The obvious issue with this is "who could declare a specification to be rigorous?" Do you feel you have the correct background for this task, or do you see a better way to ensure MS (or any other software vendor for this matter) respects their obligations?I agree that the whole refinement of specifications idea is fantastically straightforward in principle, but that in practice this is not necessarily so. Practical specifications are frequently hopelessly woolly bloated mammoths, and far too frequently (in my experience at least) require provably impossible behaviours of systems - which is amusing until you realise you've wasted days concerning yourself with an impossible aspect of the design about which nobody cares!
My argument is that programmers must behave primarily as artists not as scientists. This doesn't mean I don't think that formal techniques and tools are anything other than invaluable. On the contrary, I believe that exactly these techniques set software apart from other art forms. Software is unique in that it should be possible to evaluate software objectively, however, until computer professionals agree how comparisons should be made, I feel we are doomed to remain in the dark ages with a prevalence of shoddy projects plagued by avoidable bugs.
The specification and design of software, and in this I also refer to detailed refinement of the design until you arrive at an executable product is an art, not a science. If it were a science for which we can define a satisfactory set of rules to ensure a quality product emerges, then I'd write a program to write programs and we'd all become redundant. Reductio ad absurdium!
As the design aspect of software - every time a choice has to be made to move from one high level idea to a concrete implementation - then this requires a subjective decision. If we want to improve software quality, then we need to take an entirely different approach. We still need the coding artists, in order to come up with ideas, and we need the specification artists to capture ill-defined scenarios to the best of their ability. The interesting stage comes thereafter... once we've arrived at a specification and implementation. The specification can be assessed depending upon whether a system meeting this specification performs well once deployed. The software can be assessed upon several criteria - significantly including:
1) Satisfaction of the specification that came before (should be 100%)
2) Resources consumed to realise each interaction (the less the better) - Code side; memory use; disk reads; wall clock time required; interactive response etc.
3) Availability of formal proofs that a specification is satisfied.
4) Burden of assumptions made about any underlying technology, and failure model assumed to cope with unexpected events and failures.
What we need is a robust way to specify requirements; and indisputable ways to show when an implementation doesn't meet a specification - and a strategy by which alternate implementations of small components can be compared in the context of the project specification.
While I find the STL invaluable, my experiences with it under VC6 leave me less than impressed. I've encountered problems with relation to multiple threads, which proved most unpleasant. While, as anyone who has used the STL for more than "hello world" will know, the STL is not thread safe. The problem arises in determining the acceptable ways in which an STL object can be used in a multithreaded application. At first I assumed that it was acceptable to wrapper access to each object with a critical section, but came to realise after several hours that this was inadequate for MSVC 6 STL in light of certain functions depending upon the use of static internal attributes... hence requiring me to impose a global scope critical section whenever I accessed any of my container objects derived from STL bases. It is also important to realise that the signatures to certain methods are not the same as in other implementations... I particularly recall differences between MS's erase() and the status quo suggested by platform independent STL documentation.
Some "bugs" are reported by Dinkumware, who purport to have written the VC6 STL, but also offer to sell a "better version". I also remember Service pack 4 breaking the STL, which was reverted in service pack 5. I have had less problems with the STLport implementation, but any developer considering a design based on multiple threads and the standard MS VC6 STL should beware!
Broadband will take off when it is cheaper to have broadband for a month than pay for a dialup bill... We need mass take-up for broadband to really take off, and that means making it a cost effective option for occasional users who currently enjoy their hour online each month for at most a few pence. Maybe the answer to this is to start charging by the MB for transfers? I suppose that would mean people would need to run a secure OS too to avoid extortionate bills:-)
From my perspective, while obscenely large limits on file system sizes are no bad thing, I'm more interested by the prospect for scalability in the context of realistic problems. I see much larger challenges in establishing systems to maximally exploit locality of reference. I'd also like to see memory mapped IO extended to allow direct use to be made of entire large scale disks in a single address space using a VM-like strategy ... but I guess this will only be deemed practicable once we're all using 64 bit processors. Are there any projects to approximate this on 32 bit architectures?
In my experience, the ability to give an estimate as to a timescale is extremely useful when it comes to planning. When a knowledgeable person asks how long a problem will take, I'm taken to one of these options:
I have found I've got better at my estimates as I become more experienced... I've also learned that using terminology like "a few
Having first heard about FPGA tech a few years ago, and realising that while it presented some interesting "tricky" problems, I completely failed to think of one application proving both interesting and vaguely plausible for which an FPGA would be the best practical "way to go". Recently I had several ideas - for which only IO bandwidth seemed an unavoidable problem. Is there someone who can comment on the feasibility of implementing:-
At work we recently had a discussion about the current state of viruses - and our consensus was that most were thankfully reasonably benign - in real terms they were simple to detect and eradicate. I for one hope we don't return to the old-school where executables are modified and viruses interact with the OS at the lowest levels - gradually damaging data in order to ensure that errors are propagated thorough grandfather-father-son backups. This sort of low-level virus was a serious problem in days of yore... and can you imagine trying to detect a binary level real-time encrypted/decrypted monster for which there is no clear signature. What a nightmare that would be - at least right now the most prevalent damage seems to be to pride rather than mission critical data.
I'd postulate that without this flurry of viruses that have plagued Windows of late, the masses would still be completely ignorant of security issues. By causing embarrassment, affected users are likely to remember their mistake and avoid future repeats - not that I think virus writing is in any way justifiable. Sure - releasing exploit information to live systems is dangerous - expanding the availability of this information certainly damages the security of the systems in question. However, we all know that the real problems lie with the abominable quality of MS closed source systems.
There is a solution - to both this and the problematic anti-competitive claims - we need legislation. We must require all organisations using computers to manage personal information (in the UK exactly that information which is covered by the DP act) to only use suppliers who fully disclose all interfaces to their systems for public inspection. I don't believe that we should require Open Source (although that certainly meets the requirements of specification) - but I believe that a supplier who falsely, or incompletely documents a formal specification should be held liable without limit for any consequential damage which can be attributed to any discrepancy between the system and it's specification. Simple, effective and our only defence against "evil terrorists" otherwise minority groups with selfish agendas will surely wreak havoc be on the free and democratic world. Start the lobbying!
My take on this question is that I'm sure that there is loads of fun work out there - although in the environment of limited funding changing jobs should not be taken lightly. However, for myself, a fun job is one where I'm given sufficient freedom and resources to make me productive. If you can solve problems you will be a valued employee and even when jobs are scarce - you will find work with any organisation that feels they can trust you.
That said, I enjoy solving non-obvious problems, love technology and have been obsessed by software for over a decade. I hate computer games, love good food and think that a friendly, light and well-equipped workplace can't be over valued. I'm very aware that jobs I find interesting are "dangerous" but this is because I like adventurous ventures. This is why I do work for others. I've been asked to recommend others for jobs I'd find interesting, but I've had to explain that everyone I know who is up to the job is in well-paid stable employment - good people are still hard to find.
I hope my post was "Funny,3" because there was no "Ironic" tag available to moderators...
It was a serious remark - if there was a way to have people who send me email charged, I would use it... assuming this did not make it any more time consuming or difficult to contact me. If every mail cost the same as a cheap phone call, then I'd be happy. I can't think of anyone from whom I would like to hear being unwilling to bear such a cost, but I would imagine this eliminating the vast majority of my unwelcome mail. In order for this idea to be a success, then user authenticity must be addressed first enabling me to choose not to receive email from accounts without a verified real-world identity.
All we all need is Microsoft to introduce a new email variant where the sending party is charged for each email sent, hence diminishing the wish of users to impose unnecessary noise.
In the UK we have "The data protection act" which allows anyone over the age of 18 to demand a printed copy of all personal information stored about them online (and now, I understand, offline, for example printed) records. The glitch is that a "reasonable search fee" is acceptable (about which I'm annoyed) but the company is required to amend any inaccurate or unnecessary records.
Doesn't America have one of these? Has anyone actually challenged MS to provide a printed breakdown?