And equally Open Source doesn't work because there is no controlled review process. In most (not all) projects only one pair of eyes will every consider a particular piece of code. Another may touch on it in passing. But seldom is each function thoroughly reviewed, line by line, for correctness.
Open Source gives you the ability to have a million eyes inspecting the code. It doesn't necessarily cause that the happen.
What we need in the FLOSS world is a code review system similar to Project Gutenberg's distrbuted proofreaders. Every time code is checked into a (CVS) repository it is analysed to determine the effected function / class / file, and the before and after snippets are sent off to be reviewed by (say) 3 independent reviewers (at least one who is recognised as a "senior" reviewer). Alternatively a patch is submitted and must pass 3 reviews before being committed.
A catch to this suggestion is that it only works properly if the function interface is properly documented, and the system is able to determine the call graph and invalidate the review of all calling functions (and their callers, etc) if the function interface changes (as attested to be a reviewer).
This is very true. I think that a lot of children are desensitised to violence not because they see a lot of it (Hollywood style), but because they don't tend to see the consequences of it. In Hollywood movies people get shot / hacked up / whatever, and its all good clean fun. There's a bit of tomato sauce here and there, but there's no wailing wives / parents / children, no rotting in jail until you wither and die, no consequence.
Let's pick on Star Wars for a moment. Consider the Ewoks in "Return of the Jedi". They through their hearts into a hopeless battle, and they get hurt, and they die. Their comrades / partners start crying about it. Things look very grim.
Not so in The Phantom Attack of Menacing Clones. Gungans go down in their thousands in a comedy epic of explosive balls. Jedi Masters are nicely and cleanly slaughtered. At what point do kids get any idea that violence is a bad thing?
Forgive me for assuming something more intelligent than a signed fingerprint.
The on-chip data should include all data visible on the passport (your name, passport number, age, etc) plus a picture and other biometrics as appropriate, all signed together.
Since a computer will be reading and logging this info, and assumedly checking it against a database of who was supposed to be on the plane, known terrorists, MP3 pirates and senators, I thought it too obvious to state that this info would be in electronic form and digitally signed.
Yes, you can load the signed data onto a different card. No, it doesn't break the system, because what is printed on the card is just there to be pretty. All real information and safeguards are electronic.
Signing it with a public key algorithm is a good idea, but it only takes one official to sell the private key to a forger
Clue: institutions that are serious about security don't store private keys where they can be retrieved. They use a device called a "Hardware Security Module" (HSM). This device will protect its contents from just about anything you can throw at it if you aren't a government; it does this by securely erasing all sensitive data without the possibility of retrieval. These devices generate the key pair and never allow the private key to be exported. Some types are insecure enough to allow the private key to be duplicated into another HSM, but only if you have a pair of trusted custodians who have to enter symmetric key components into the HSM for this purpose. The entire system is operated in a secure facility with access control systems, so that no-one without the necessary authorisation gets in to play with or steal the HSM (not that it would do them any good).
This is how security works in banks and governments. So you've heard that bank security sucks? Yes, it does. Because they don't know how to use HSMs properly, or design a secure cryptographic system. All the attacks on banks are against IT infrastructure, protocol weaknesses or are social attacks on authentication.
You're right, its not secure. But not for the reasons you have cited.
This is a correct use of biometrics. The use here is in identification, not authentication. In addition the biometric is one factor involved in identification, the other being a physical token (the passport itself).
In this context, faking the biometric is hard (but obviously not impossible). If you steal someone's passport then you need to make your biometrics appear to be their's, i.e. change you face, your fingerprint, etc. Fooling a single scanner is not sufficient to fool the system, since you will be subject to passport checks to leave and enter different countries, and the scanner will be operated by a person (giving you extremely limited opportunity to fool it).
Why this system would appear to be grossly insecure is all the talk about encrypted traffic from the card. This requires some sort of shared secret key architecture, unless every request goes via a central repository for the particular passport issuer (in which case the passport can share a unique key with its issuer, and the issuer can send the data back to the scanner). This would have a ridiculous amount of overhead in terms of identification time and implementation effort, not to mention problems with "the system is offline".
Making this system sufficiently secure is not difficult, but requires some careful thought. The first step is to have each passport issuer sign the biometrics and publish its public certificate. Then creating a fake passport is practically impossible (although bribing an official to have one created is still relatively simply).
Solving the privacy issue is harder. You have to allow certain scanners (customs, perhaps your travel agent, bank, etc) to read the information, but not allow it to be "sucked" from your pocket on the street. The simplest solution is to keep your passport in a sleeve that retarts the contactless communication. Another is to have a shared secret key architecture, and yet another is to have an online system that requires the passport issuer as a "trusted third party". Perhaps the best solution would be to have a card with a button or pressure sensitive region so that it only communicates when pressed, preventing identification without your explicit content.
You're basing your entire argument on the assumption that bad code is a faster route to a deliverable project. See my other responses in the thread for why this assumption is not true.
You missed my point. I regularly work on insufficient information to deliver a completed product that was ordered today and wanted yesterday.
My point is that in any non-trivial implementation, it is faster - from a purely getting-the-code-working viewpoint and and whether the requirements or design change or not - to approach programming in a methodical way with forethought, consideration, and proper documentation.
A program you write in this way has an excellent chance of working correctly with little debugging, while hack jobs often contain logic and/or coding bugs, which can be extremely difficult to track down without source documentation (especially in a team environment). Writing unit tests as you go also speeds the development process, rather than slowing it down.
Let me provide a (partially) contrived example: while working in a team to create firmware for an embedded system, I need to retrieve some structured data from NVRAM. First, proper documentation and/or communication with team members quickly will tell me whether or not there are existing utility functions to access NVRAM and retrieve this particular structured data. Second, proper documentation will tell me exactly how to use functions (how to populate the parameters, how errors are returned, etc). This makes the difference between writing C using the standard headers for reference, or using man/MSDN for reference. Third, having a unit test for the utility functions tells me that they behave correctly within their described bounds, so when I am debugging my code I can (largely) trust that the utility functions work, or at least only check them as a last resort.
I also have experience in less mature teams. The first thing I see is duplicated code -- team members don't communicate or read documentation (if it exists) and simply write new functions to do what they need to get done. Second, programmers in such environments spend a lot of time figuring out the correct way to call a particular function, and (if they even understand the idea of checking for error returns) figuring out what is or isn't an error return. I have often seen snippets of prototype code (test_001.c with a main() method and little more) that are just used to figure out the correct way to call a function. Finally, when the program doesn't work (which is always), a huge amount of time is wasted stepping through every line of code, trying to determine where the fault lies. The worst part of this is that in this debugging process a lot of knowledge is gained by a single team member (such as that particular underlying functions appear to behave correctly) that is not properly shared (another member will have a problem and trace through the same code the next day).
Taking a pragmatic approach to coding may mean that you take longer to write the code, but it will be up and working (without memory leaks, overflows, logic bugs relating to error handling, etc) much more quickly than the hack and debug approach.
This is precisely why the paired programming approach works: one brain writing the code and the other brain checking it provides a much greater degree of certainty that the initial quality of code is good, and obvious coding and logic bugs won't be present.
The case study in the article makes the point of how difficult it is to search and replace when there are different representations for color. Nice example, but coding style is the wrong approach to solve this.
Firstly, if you really have 3000 lines of style sheets (oh dear, a whole 3000) and you're using a consistent color scheme (which you must be if you're replacing the same color all over the place) then you really want to define your color scheme (usually primary, secondary and tertiary foreground and background colors, plus "white" and "black") and preprocess the stylesheets.
Second, "search and replace" and "cut and paste" should only be used by a miniscule number of ridiculously competent developers who fully understand the risks and have the patience and account-type mentality to use them properly. Unfortunately this functionality is usually used by less experienced developers looking for a shortcut.
I can't count the number of times that I've seen a search-and-replace destroy fragments of unrelated code, or a cut-and-paste has led to weird shit happening. Unless you check what is being changed with a fine tooth comb, you're leaving the results to assumption. And there is much to be said about assumption... none of it good.
Fortunately the rest of the article is right on target with its approach to quality and productivity.
How are "good" and "bad" programmers measured? Whether I'm doing paid-for commercial development or working with a team for free, my criteria for a "good" programmer is the same: produce code that performs its intended purpose, is reliable, and is maintainable. The question of maintainability includes considerations such as design (in the small), style, and documentation.
The idea that deadlines lead to bad code is a fallacy, and a self fulfilling prophecy. Code that is written well the first time has less bugs, which are more easily tracked down, and is easier to integrate with. Unfortunately those that cling to this mantra tend to believe that the only way to meet a tight deadline is a hack job.
Communication is important in code quality and in meeting deadlines. Communication provides a way to learn -- about better ways to do things, about how the program flows, about what utility functions are available, about how not to reinvent the wheel, and about who can give you a quick answer to a problem that may require half an hour of searching through a large code base. All of which contribute to better code and greater productivity.
Most important, communication allows a team to inform a member who thinks (s)he is somehow special or better, that "programming" and "software engineering" are different disciplines, and that the latter is required for long-term success.
Why? Because it doesn't have a little graphical paperclip saying "Would you like to install the OS?"
Ok, first a correction to what I said before. Now that I've thought about it, I was probably playing with OpenBSD 2.8, and that was about three years ago. I've looked at the new install walkthrough on openbsd.org and things look a little better -- still, a lot of these comments apply.
Not because my favourite paperclip is missing, but because the entire install was command line based, a number of details that had to be provided were non-obvious (e.g. the device path for the partition on which to install) and had to be specified rather than chosen from a list (the new installer appears to give choices and a default).
When I install an OS to try it out I don't have time to get familiar with its intricies (likes its naming scheme for devices or how to configure networking). I also consider the install and use of the OS from the perspective of an administration who is not familiar with *nix (but is willing to learn the basics).
In that respect, Monowall gets full marks. Its a breeze to install and get it working -- took me five minutes (including the download, write to CD and boot). I also give FreeBSD high marks -- it has critical functionality out of the box (with little configuration needed), the install is sufficiently friendly (I have given it to an MS admin with no *nix support before and he managed, without any documentation). But, IMHO, most MS admins would struggle with an OpenBSD install (certainly the version I used).
If you has some "incompatibilites", I'd be even more interested.
Intermittent IDE drive problem, the drive kept, um, "resetting". I had a similar problem with a Linux kernel (different controller and drive) about 6 years before; I know the Linux failure is "DriveReady/SeekComplete". FreeBSD, Linux and WinNT worked on this hardeware, but OpenBSD didn't.
*thumbs up* I haven't played with OpenBSD in about a year, but back then I found it unfriendly to install and encountered some hardware incompatibilities. I've always found FreeBSD to be thoroughly stable and reliable as a server OS.
As a firewall may I recommend MonoWall. It is a single CD (around 6Mb) BSD-based firewall/NAT solution with web-based administration, and is absolutely brilliant.
Imagine a server in which you have a thread for accepting input from sockets, several processing threads (for various stages of processing), and one for sending output to sockets. These threads communicate by means of queues, access to which is controlled by a mutex. Aside: there are often dozens of processing threads in this sort of architecture, and processing ranges from sub-second to a minute or more
Now consider the output thread. It needs to wait on the mutexes of several queues and know when sockets (that have had their buffers filled) become writable.
Just waiting on multiple mutexes is a problem under *nix, but it can be avoided by reducing the number of mutexes and increasing the opportunity for lock contention.
Let me point out that if you are designing a system, knowing that it is targetting a *nix-style threading model, then you can avoid these problems. But the Win32 model allows a more straightforward approach (without sacrificing performance), and, if you already have a Win32 program using the functionality of that model, its a complete bitch to port to *nix.
OMG you're insane! I mean I stood up for Windows on Slashdot, but you're standing up for COM!? Please move away and hand me some extra asbestos;)
In terms of security your comments about review are certainly accurate. OTOH MS does have role-based security build into the kernel, which Linux doesn't. I would be inclined to say that the MS kernel has the potential to be more secure than Linux, but probably isn't at the moment. This comment doesn't extend beyond the kernel!
In terms of synchronisation, a popular architecture on Win32 is a sequence of producers and consumers (each producer consuming from the one before it) using queues to communicate. It is a highly scalable architecture, and can be very efficient if each "stage" in the line is served by multiple worker threads. Although there are several approaches to implementation, two are of concern for Win32-Unix portability:
(1) Having a mutex per producer reduced lock contention, but this assumes that a consumer can wait on multiple mutexes.
(2) You can have all IO handled by a single thread, or all input handled by one thread and all output handled by another. There are some nice reasons involving performance and abstraction that you may want to do the former, but it is only possible if you can wait on sockets and the mutexes for the producer queues (they have finished processing and want to send output). In fact just an output thread can face this problem if it has to wait for producer queues or for sockets to become writable.
Actually I completely agree with you about the need for a userspace standard like COM but... well, done right;)
Power doesn't always equate to performance. In most tests Win32 comes in 5-10% slower on throughput. On the other hand Win32 has long had pretty good scalability (via completion ports) that was never available to *nix based servers using select() (or even poll() , but kqueue and/dev/poll make a big difference).
The Developerworks article tests Win32 against *nix using BSD-style socket calls. That's slightly unfair, because its an emulated API on Win32 but native on Linux. Still, it doesn't account for the speed differences.
My explanation of that test would be that Win32 has a fair scheduler (round-robin thread-level scheduling for all threads at the same priority) -- so even if a thread has a history of being busy it will be interrupted to give other threads a turn. Back in 2001 the Linux scheduler was not nearly that fair (although its never been as bad as the Solaris scheduler, which routinely blocks out historically idle processes when others are under heavy IO load).
You also miss the point about the wait operation. Spin checks in user land suck processing time from other threads/processes, and can compromise system responsiveness and performance. The only way to wait for either a mutex or a socket from one thread is to sit in a loop polling them. Its a similar story if you want to wait for any one of several mutexes -- poll. Win32 provides a kernel-level synchronisation primitive that will only wake your thread when the appropriate condition(s) hold.
Sorry fuckwit, but I learned multithreading and most of my programming skills on FreeBSD and Linux. At some point you have to use your ridiculously fucking power general purpose threads and asynchronous IO to solve a problem rather than just mentally masturbating about it on Slashdot, and in some instance that problem might just be that you need to resume processing once either a mutex is available or a socket is readable. If you every studied software engineering you'd probably even think about abstracting that particlar problem as a function if you use it more than once. But guess what? You can't solve that problem on Linux, because it doesn't have the kernel primitives to facilitate waiting on IO and synchronisation events simultaneously. So take a flying fuck off a short pier, get a clue what you're talking about before you sprout your shit, and perhaps you may want to read some books on why developers who know a fuckload more than you do think that the Win32 threading and synchronisation model is more powerful for application development than anything available in the *nix world.
So here's a programming challange for you. Create a function that takes a mutex, a file/socket handle and a timeout as parameters, and returns when the first of (mutex available, IO readabe, timeout occurred) happens.
Oh, and don't do something like userland polling. This has to prove that the scheduler can wake a thread under those conditions, not that you can sit in a busy loop checking the environment.
Hint: you can't do it. The IO waiting primitives provided by the kernel (select, poll,/dev/poll, blocking and non-blocking IO, etc) are completely divorced from the synchronisation primitives that are available. But don't believe me... ask Google about WaitForMultipleObjects unix.
Win32 has blocking, non-blocking and asynchronous modes of IO. But where it really shines is the integration between IO and scheduling (from a developer perspective).
The call WaitForMultipleObjects allows you to wait on any number of objects, for any or all of them to be signalled. Each object can be a thread, an IO resource (file, socket, pipe), a synchronisation primitive (mutex, event, semaphore), etc.
The other point of integration is Completion Ports. You can provide worker threads and asynchronous callback functions (to be invoked in the worker threads) to any IO operation.
POSIX AIO provides most of the functionality (with regard to IO) that one can desire (Completion ports are cute and offer a lot of potential for performance, but you can do an equivalent job with kqueue/poll/devpoll and/or aio). But POSIX AIO doesn't offer developers control over the integration between the scheduler and IO.
Thank you for displaying your profound lack of knowledge of MS operating systems.
The kernel behind Windows 2000/2003 is as solid as Linux. Crashes are almost without exception the result of third party device drivers. The perceived frailty of MS is (a) a hangover from the Win95/98/Me crap and (b) because of the UI and application communication layers, not the kernel.
As a developer I get to see the side of Windows and Linux that many don't -- low level interfaces to system functionality. And many aspects of Windows, from a developer perspective, are ahread of *nix.
The Win32 threading and synchronisation models are ridiculously powerful compared to *nix, which is precisely what makes it so hard to port a lot of Win32-based software to other platforms. The fact that you can't do a simple operation like "wait for a mutex to be released or a socket to become readable" deserves to be a joke about legacy operating systems, not a persistent reality. At least BSD's kqueue comes close.
There are many other places in which the *nix kernels show their age compared to the design of Win32 (not to mention MS's ability to maintain a consistent API over 10 years of product developments). 30 year old technology may be "mature", but its not always The Right Thing To Do for the future.
So try to get the facts before you succumb to FUD about the state of computing -- from MS or FLOSS.
Couldn't agree more. The last three games I've bought won't run on my PC because of copy protection issues. A forth only ran because I installed a completely clean copy of Win98, but the sound didn't work until I downloaded a large patch. And of course, once opened, no store will accept the game back.
I won't buy a game anymore unless I know that I can download and run a cracked version, so that I know I can actually realise my investment.
First, get yourself a thorough check by a reputable optometrist. And I don't mean a "15 minutes and we throw in the glasses for free" franchise.
I get eye strain from a condition in which my eyes are not horizontally aligned, so focusing on a point involves one eye pulling in and downwards -- and you eye muscles aren't made to do that for an extended period. Conditions like this are not detected by slap-dash consultations.
Here are a couple of other important factors:
Allergies: if you have an allergy to something in your environment (e.g. dust), this can cause dryness and itching, which are often associated with eye-strain.
Air conditioning: especially significant for people who aren't used to working in an air conditioned office, the air con reduces humidity and can dry out your eyes.
Flourescent light: Usually not so much of a problem these days, but flourescent lights can still flicker, and they provide a very hard light. A lot of desk workers (not computer-based) get headaches from flourescent light!
Refresh rate: up your monitor's refresh rate. 60Hz is WAY too low -- don't use anything below 72Hz, 75Hz plus is preferable.
Resolution: a lot of people like working at 1600x1200 on a 17" monitor. They will strain their eyes (even without realising it) and have to clean nose marks off the monitor just trying to read Slashdot. The ratio of resolution to physical size is important -- I wouldn't recommend going over 1024x768 on a 17" (CRT).
Background colour: background/foreground contrast can add to eye discomfort. The best background colour is a neutral blue. Blue is even better than gray. You'll find more details on this in a good Human-Computer Interface textbook.
Brightness and contrast: if someone comes into your office and is shocked at your screen brightness, believe them -- its too bright. You should aim for your background colour to be matt, like a piece of paper under the same lighting conditions.
I have to agree with you. Linux advocates don't understand TCO. The cost of initial hardware and software is a minor component of TCO. Major components are the retention of suitably trained staff, cost of enterprise systems or development, and optimising productivity of the system as a whole.
Microsoft administrators are often cheaper and come with less brainpower than their *nix counterparts. This makes it cheaper to retain MS trained staff. It is also (generally, thus far) cheaper to outsource Microsoft-based network management.
Enterprise development is also, thus far, cheaper on Microsoft platforms. These platforms have all the tools to develop large systems quickly and effectively. Few organisations are writing their enterprise systems in C anymore! In this respect Java is providing a lifeline to Linux. An equally important consideration is the available of enterprise platforms off the shelf, most of which support *nix (but not Linux) or Windows platforms.
Optimising productivity is again often misunderstood. OS performance is an insignificant factor. Application performs is more significant, but still minor. Since (arguably) the best enterprise "tool" on Linux is Java, and Java is still relatively slow on the desktop, Linux loses on this aspect. Network performance quite important, and Linux is only slightly ahead of Windows (on a WINS network) if you don't have services for automatic network discovery and integration installed.
The real biggies in productivity are avoiding downtime, having the right applications for the job (i.e. productivity applications), and having the right skills to use the application. While workstation failures are irritating (and, frankly, Linux has at most a 10% lead in stability in that environment), network outages (not an OS consideration) and server failures are where the problems lie.
Take a look at the unplanned downtimes of a well-maintained Windows server on good hardware is the correct environment (clean room, UPS, cooling, etc). Three nines is not difficult to achieve. There is only one provider of hardware that guarantees five nines uptime using a non-proprietory OS... take a guess: its a Windows OS.
Finally, in terms of productivity applications and available skills and/or training, Linux can't touch Windows. They are literally hundreds or applications for every purpose out there that are smooth and polished and do what a business wants. More importantly, you'll easily find staff that are experienced with that package, and that's a huge cost saving.
So yes, Linux is free and cheap and all that, and has tons of applications, and can do amazing stuff. But it doesn't do it out of the box, few people know the desktop environment or the applications, and it takes a less common skillset to configure, administer, maintain and develop in a Linux environment. All of which push up the long term TCO, and allow you to make a very valid cost comparison with Windows.
Windows has virtual desktops. The support has been provided at OS level since Windows NT ; you just need to get a utility to use them. Try Virtuawin, its even OSS.
Unfortunately "one size fits all" solutions seldom work. My SO worked in the buying department of a large retail group, who decided to start clearing out e-mail over 60 days old. Problem is the department has to place orders on suppliers 6 to 9 months before delivery. By the time delivery rolls around, most tracability is lost, including date estimates which suppliers swear they didn't commit to.
Now all of this can be handled by printing out the e-mails (ack!), but you sort-of need to know to do this before the delete everything, right? Go figure.
Slashdot Mirror
Also worth looking at is SWISH-Enhanced. It can deal with Word .docs (with a bit of configuration), PDF, HTML and anything you can filter to text.
And equally Open Source doesn't work because there is no controlled review process. In most (not all) projects only one pair of eyes will every consider a particular piece of code. Another may touch on it in passing. But seldom is each function thoroughly reviewed, line by line, for correctness.
Open Source gives you the ability to have a million eyes inspecting the code. It doesn't necessarily cause that the happen.
What we need in the FLOSS world is a code review system similar to Project Gutenberg's distrbuted proofreaders. Every time code is checked into a (CVS) repository it is analysed to determine the effected function / class / file, and the before and after snippets are sent off to be reviewed by (say) 3 independent reviewers (at least one who is recognised as a "senior" reviewer). Alternatively a patch is submitted and must pass 3 reviews before being committed.
A catch to this suggestion is that it only works properly if the function interface is properly documented, and the system is able to determine the call graph and invalidate the review of all calling functions (and their callers, etc) if the function interface changes (as attested to be a reviewer).
This is very true. I think that a lot of children are desensitised to violence not because they see a lot of it (Hollywood style), but because they don't tend to see the consequences of it. In Hollywood movies people get shot / hacked up / whatever, and its all good clean fun. There's a bit of tomato sauce here and there, but there's no wailing wives / parents / children, no rotting in jail until you wither and die, no consequence.
Let's pick on Star Wars for a moment. Consider the Ewoks in "Return of the Jedi". They through their hearts into a hopeless battle, and they get hurt, and they die. Their comrades / partners start crying about it. Things look very grim.
Not so in The Phantom Attack of Menacing Clones. Gungans go down in their thousands in a comedy epic of explosive balls. Jedi Masters are nicely and cleanly slaughtered. At what point do kids get any idea that violence is a bad thing?
Forgive me for assuming something more intelligent than a signed fingerprint.
The on-chip data should include all data visible on the passport (your name, passport number, age, etc) plus a picture and other biometrics as appropriate, all signed together.
Since a computer will be reading and logging this info, and assumedly checking it against a database of who was supposed to be on the plane, known terrorists, MP3 pirates and senators, I thought it too obvious to state that this info would be in electronic form and digitally signed.
Yes, you can load the signed data onto a different card. No, it doesn't break the system, because what is printed on the card is just there to be pretty. All real information and safeguards are electronic.
Clue: institutions that are serious about security don't store private keys where they can be retrieved. They use a device called a "Hardware Security Module" (HSM). This device will protect its contents from just about anything you can throw at it if you aren't a government; it does this by securely erasing all sensitive data without the possibility of retrieval. These devices generate the key pair and never allow the private key to be exported. Some types are insecure enough to allow the private key to be duplicated into another HSM, but only if you have a pair of trusted custodians who have to enter symmetric key components into the HSM for this purpose. The entire system is operated in a secure facility with access control systems, so that no-one without the necessary authorisation gets in to play with or steal the HSM (not that it would do them any good).
This is how security works in banks and governments. So you've heard that bank security sucks? Yes, it does. Because they don't know how to use HSMs properly, or design a secure cryptographic system. All the attacks on banks are against IT infrastructure, protocol weaknesses or are social attacks on authentication.
You're right, its not secure. But not for the reasons you have cited.
This is a correct use of biometrics. The use here is in identification, not authentication. In addition the biometric is one factor involved in identification, the other being a physical token (the passport itself).
In this context, faking the biometric is hard (but obviously not impossible). If you steal someone's passport then you need to make your biometrics appear to be their's, i.e. change you face, your fingerprint, etc. Fooling a single scanner is not sufficient to fool the system, since you will be subject to passport checks to leave and enter different countries, and the scanner will be operated by a person (giving you extremely limited opportunity to fool it).
Why this system would appear to be grossly insecure is all the talk about encrypted traffic from the card. This requires some sort of shared secret key architecture, unless every request goes via a central repository for the particular passport issuer (in which case the passport can share a unique key with its issuer, and the issuer can send the data back to the scanner). This would have a ridiculous amount of overhead in terms of identification time and implementation effort, not to mention problems with "the system is offline".
Making this system sufficiently secure is not difficult, but requires some careful thought. The first step is to have each passport issuer sign the biometrics and publish its public certificate. Then creating a fake passport is practically impossible (although bribing an official to have one created is still relatively simply).
Solving the privacy issue is harder. You have to allow certain scanners (customs, perhaps your travel agent, bank, etc) to read the information, but not allow it to be "sucked" from your pocket on the street. The simplest solution is to keep your passport in a sleeve that retarts the contactless communication. Another is to have a shared secret key architecture, and yet another is to have an online system that requires the passport issuer as a "trusted third party". Perhaps the best solution would be to have a card with a button or pressure sensitive region so that it only communicates when pressed, preventing identification without your explicit content.
You're basing your entire argument on the assumption that bad code is a faster route to a deliverable project. See my other responses in the thread for why this assumption is not true.
You missed my point. I regularly work on insufficient information to deliver a completed product that was ordered today and wanted yesterday.
My point is that in any non-trivial implementation, it is faster - from a purely getting-the-code-working viewpoint and and whether the requirements or design change or not - to approach programming in a methodical way with forethought, consideration, and proper documentation.
A program you write in this way has an excellent chance of working correctly with little debugging, while hack jobs often contain logic and/or coding bugs, which can be extremely difficult to track down without source documentation (especially in a team environment). Writing unit tests as you go also speeds the development process, rather than slowing it down.
Let me provide a (partially) contrived example: while working in a team to create firmware for an embedded system, I need to retrieve some structured data from NVRAM. First, proper documentation and/or communication with team members quickly will tell me whether or not there are existing utility functions to access NVRAM and retrieve this particular structured data. Second, proper documentation will tell me exactly how to use functions (how to populate the parameters, how errors are returned, etc). This makes the difference between writing C using the standard headers for reference, or using man/MSDN for reference. Third, having a unit test for the utility functions tells me that they behave correctly within their described bounds, so when I am debugging my code I can (largely) trust that the utility functions work, or at least only check them as a last resort.
I also have experience in less mature teams. The first thing I see is duplicated code -- team members don't communicate or read documentation (if it exists) and simply write new functions to do what they need to get done. Second, programmers in such environments spend a lot of time figuring out the correct way to call a particular function, and (if they even understand the idea of checking for error returns) figuring out what is or isn't an error return. I have often seen snippets of prototype code (test_001.c with a main() method and little more) that are just used to figure out the correct way to call a function. Finally, when the program doesn't work (which is always), a huge amount of time is wasted stepping through every line of code, trying to determine where the fault lies. The worst part of this is that in this debugging process a lot of knowledge is gained by a single team member (such as that particular underlying functions appear to behave correctly) that is not properly shared (another member will have a problem and trace through the same code the next day).
Taking a pragmatic approach to coding may mean that you take longer to write the code, but it will be up and working (without memory leaks, overflows, logic bugs relating to error handling, etc) much more quickly than the hack and debug approach.
This is precisely why the paired programming approach works: one brain writing the code and the other brain checking it provides a much greater degree of certainty that the initial quality of code is good, and obvious coding and logic bugs won't be present.
The case study in the article makes the point of how difficult it is to search and replace when there are different representations for color. Nice example, but coding style is the wrong approach to solve this.
Firstly, if you really have 3000 lines of style sheets (oh dear, a whole 3000) and you're using a consistent color scheme (which you must be if you're replacing the same color all over the place) then you really want to define your color scheme (usually primary, secondary and tertiary foreground and background colors, plus "white" and "black") and preprocess the stylesheets.
Second, "search and replace" and "cut and paste" should only be used by a miniscule number of ridiculously competent developers who fully understand the risks and have the patience and account-type mentality to use them properly. Unfortunately this functionality is usually used by less experienced developers looking for a shortcut.
I can't count the number of times that I've seen a search-and-replace destroy fragments of unrelated code, or a cut-and-paste has led to weird shit happening. Unless you check what is being changed with a fine tooth comb, you're leaving the results to assumption. And there is much to be said about assumption ... none of it good.
Fortunately the rest of the article is right on target with its approach to quality and productivity.
How are "good" and "bad" programmers measured? Whether I'm doing paid-for commercial development or working with a team for free, my criteria for a "good" programmer is the same: produce code that performs its intended purpose, is reliable, and is maintainable. The question of maintainability includes considerations such as design (in the small), style, and documentation.
The idea that deadlines lead to bad code is a fallacy, and a self fulfilling prophecy. Code that is written well the first time has less bugs, which are more easily tracked down, and is easier to integrate with. Unfortunately those that cling to this mantra tend to believe that the only way to meet a tight deadline is a hack job.
Communication is important in code quality and in meeting deadlines. Communication provides a way to learn -- about better ways to do things, about how the program flows, about what utility functions are available, about how not to reinvent the wheel, and about who can give you a quick answer to a problem that may require half an hour of searching through a large code base. All of which contribute to better code and greater productivity.
Most important, communication allows a team to inform a member who thinks (s)he is somehow special or better, that "programming" and "software engineering" are different disciplines, and that the latter is required for long-term success.
Ok, first a correction to what I said before. Now that I've thought about it, I was probably playing with OpenBSD 2.8, and that was about three years ago. I've looked at the new install walkthrough on openbsd.org and things look a little better -- still, a lot of these comments apply.
Not because my favourite paperclip is missing, but because the entire install was command line based, a number of details that had to be provided were non-obvious (e.g. the device path for the partition on which to install) and had to be specified rather than chosen from a list (the new installer appears to give choices and a default).
When I install an OS to try it out I don't have time to get familiar with its intricies (likes its naming scheme for devices or how to configure networking). I also consider the install and use of the OS from the perspective of an administration who is not familiar with *nix (but is willing to learn the basics).
In that respect, Monowall gets full marks. Its a breeze to install and get it working -- took me five minutes (including the download, write to CD and boot). I also give FreeBSD high marks -- it has critical functionality out of the box (with little configuration needed), the install is sufficiently friendly (I have given it to an MS admin with no *nix support before and he managed, without any documentation). But, IMHO, most MS admins would struggle with an OpenBSD install (certainly the version I used).
Intermittent IDE drive problem, the drive kept, um, "resetting". I had a similar problem with a Linux kernel (different controller and drive) about 6 years before; I know the Linux failure is "DriveReady/SeekComplete". FreeBSD, Linux and WinNT worked on this hardeware, but OpenBSD didn't.
*thumbs up* I haven't played with OpenBSD in about a year, but back then I found it unfriendly to install and encountered some hardware incompatibilities. I've always found FreeBSD to be thoroughly stable and reliable as a server OS.
As a firewall may I recommend MonoWall. It is a single CD (around 6Mb) BSD-based firewall/NAT solution with web-based administration, and is absolutely brilliant.
Imagine a server in which you have a thread for accepting input from sockets, several processing threads (for various stages of processing), and one for sending output to sockets. These threads communicate by means of queues, access to which is controlled by a mutex. Aside: there are often dozens of processing threads in this sort of architecture, and processing ranges from sub-second to a minute or more
Now consider the output thread. It needs to wait on the mutexes of several queues and know when sockets (that have had their buffers filled) become writable.
Just waiting on multiple mutexes is a problem under *nix, but it can be avoided by reducing the number of mutexes and increasing the opportunity for lock contention.
Let me point out that if you are designing a system, knowing that it is targetting a *nix-style threading model, then you can avoid these problems. But the Win32 model allows a more straightforward approach (without sacrificing performance), and, if you already have a Win32 program using the functionality of that model, its a complete bitch to port to *nix.
OMG you're insane! I mean I stood up for Windows on Slashdot, but you're standing up for COM!? Please move away and hand me some extra asbestos ;)
In terms of security your comments about review are certainly accurate. OTOH MS does have role-based security build into the kernel, which Linux doesn't. I would be inclined to say that the MS kernel has the potential to be more secure than Linux, but probably isn't at the moment. This comment doesn't extend beyond the kernel!
In terms of synchronisation, a popular architecture on Win32 is a sequence of producers and consumers (each producer consuming from the one before it) using queues to communicate. It is a highly scalable architecture, and can be very efficient if each "stage" in the line is served by multiple worker threads. Although there are several approaches to implementation, two are of concern for Win32-Unix portability:
(1) Having a mutex per producer reduced lock contention, but this assumes that a consumer can wait on multiple mutexes.
(2) You can have all IO handled by a single thread, or all input handled by one thread and all output handled by another. There are some nice reasons involving performance and abstraction that you may want to do the former, but it is only possible if you can wait on sockets and the mutexes for the producer queues (they have finished processing and want to send output). In fact just an output thread can face this problem if it has to wait for producer queues or for sockets to become writable.
Actually I completely agree with you about the need for a userspace standard like COM but ... well, done right ;)
Power doesn't always equate to performance. In most tests Win32 comes in 5-10% slower on throughput. On the other hand Win32 has long had pretty good scalability (via completion ports) that was never available to *nix based servers using select() (or even poll() , but kqueue and /dev/poll make a big difference).
The Developerworks article tests Win32 against *nix using BSD-style socket calls. That's slightly unfair, because its an emulated API on Win32 but native on Linux. Still, it doesn't account for the speed differences.
My explanation of that test would be that Win32 has a fair scheduler (round-robin thread-level scheduling for all threads at the same priority) -- so even if a thread has a history of being busy it will be interrupted to give other threads a turn. Back in 2001 the Linux scheduler was not nearly that fair (although its never been as bad as the Solaris scheduler, which routinely blocks out historically idle processes when others are under heavy IO load).
You also miss the point about the wait operation. Spin checks in user land suck processing time from other threads/processes, and can compromise system responsiveness and performance. The only way to wait for either a mutex or a socket from one thread is to sit in a loop polling them. Its a similar story if you want to wait for any one of several mutexes -- poll. Win32 provides a kernel-level synchronisation primitive that will only wake your thread when the appropriate condition(s) hold.
Sorry fuckwit, but I learned multithreading and most of my programming skills on FreeBSD and Linux. At some point you have to use your ridiculously fucking power general purpose threads and asynchronous IO to solve a problem rather than just mentally masturbating about it on Slashdot, and in some instance that problem might just be that you need to resume processing once either a mutex is available or a socket is readable. If you every studied software engineering you'd probably even think about abstracting that particlar problem as a function if you use it more than once. But guess what? You can't solve that problem on Linux, because it doesn't have the kernel primitives to facilitate waiting on IO and synchronisation events simultaneously. So take a flying fuck off a short pier, get a clue what you're talking about before you sprout your shit, and perhaps you may want to read some books on why developers who know a fuckload more than you do think that the Win32 threading and synchronisation model is more powerful for application development than anything available in the *nix world.
So here's a programming challange for you. Create a function that takes a mutex, a file/socket handle and a timeout as parameters, and returns when the first of (mutex available, IO readabe, timeout occurred) happens.
Oh, and don't do something like userland polling. This has to prove that the scheduler can wake a thread under those conditions, not that you can sit in a busy loop checking the environment.
Hint: you can't do it. The IO waiting primitives provided by the kernel (select, poll, /dev/poll, blocking and non-blocking IO, etc) are completely divorced from the synchronisation primitives that are available. But don't believe me ... ask Google about WaitForMultipleObjects unix.
Win32 has blocking, non-blocking and asynchronous modes of IO. But where it really shines is the integration between IO and scheduling (from a developer perspective).
The call WaitForMultipleObjects allows you to wait on any number of objects, for any or all of them to be signalled. Each object can be a thread, an IO resource (file, socket, pipe), a synchronisation primitive (mutex, event, semaphore), etc.
The other point of integration is Completion Ports. You can provide worker threads and asynchronous callback functions (to be invoked in the worker threads) to any IO operation.
POSIX AIO provides most of the functionality (with regard to IO) that one can desire (Completion ports are cute and offer a lot of potential for performance, but you can do an equivalent job with kqueue/poll/devpoll and/or aio). But POSIX AIO doesn't offer developers control over the integration between the scheduler and IO.
Thank you for displaying your profound lack of knowledge of MS operating systems.
The kernel behind Windows 2000/2003 is as solid as Linux. Crashes are almost without exception the result of third party device drivers. The perceived frailty of MS is (a) a hangover from the Win95/98/Me crap and (b) because of the UI and application communication layers, not the kernel.
As a developer I get to see the side of Windows and Linux that many don't -- low level interfaces to system functionality. And many aspects of Windows, from a developer perspective, are ahread of *nix.
The Win32 threading and synchronisation models are ridiculously powerful compared to *nix, which is precisely what makes it so hard to port a lot of Win32-based software to other platforms. The fact that you can't do a simple operation like "wait for a mutex to be released or a socket to become readable" deserves to be a joke about legacy operating systems, not a persistent reality. At least BSD's kqueue comes close.
There are many other places in which the *nix kernels show their age compared to the design of Win32 (not to mention MS's ability to maintain a consistent API over 10 years of product developments). 30 year old technology may be "mature", but its not always The Right Thing To Do for the future.
So try to get the facts before you succumb to FUD about the state of computing -- from MS or FLOSS.
Couldn't agree more. The last three games I've bought won't run on my PC because of copy protection issues. A forth only ran because I installed a completely clean copy of Win98, but the sound didn't work until I downloaded a large patch. And of course, once opened, no store will accept the game back.
I won't buy a game anymore unless I know that I can download and run a cracked version, so that I know I can actually realise my investment.
First, get yourself a thorough check by a reputable optometrist. And I don't mean a "15 minutes and we throw in the glasses for free" franchise.
I get eye strain from a condition in which my eyes are not horizontally aligned, so focusing on a point involves one eye pulling in and downwards -- and you eye muscles aren't made to do that for an extended period. Conditions like this are not detected by slap-dash consultations.
Here are a couple of other important factors:
And that's my 2c. Hope its useful :).
I have to agree with you. Linux advocates don't understand TCO. The cost of initial hardware and software is a minor component of TCO. Major components are the retention of suitably trained staff, cost of enterprise systems or development, and optimising productivity of the system as a whole.
Microsoft administrators are often cheaper and come with less brainpower than their *nix counterparts. This makes it cheaper to retain MS trained staff. It is also (generally, thus far) cheaper to outsource Microsoft-based network management.
Enterprise development is also, thus far, cheaper on Microsoft platforms. These platforms have all the tools to develop large systems quickly and effectively. Few organisations are writing their enterprise systems in C anymore! In this respect Java is providing a lifeline to Linux. An equally important consideration is the available of enterprise platforms off the shelf, most of which support *nix (but not Linux) or Windows platforms.
Optimising productivity is again often misunderstood. OS performance is an insignificant factor. Application performs is more significant, but still minor. Since (arguably) the best enterprise "tool" on Linux is Java, and Java is still relatively slow on the desktop, Linux loses on this aspect. Network performance quite important, and Linux is only slightly ahead of Windows (on a WINS network) if you don't have services for automatic network discovery and integration installed.
The real biggies in productivity are avoiding downtime, having the right applications for the job (i.e. productivity applications), and having the right skills to use the application. While workstation failures are irritating (and, frankly, Linux has at most a 10% lead in stability in that environment), network outages (not an OS consideration) and server failures are where the problems lie.
Take a look at the unplanned downtimes of a well-maintained Windows server on good hardware is the correct environment (clean room, UPS, cooling, etc). Three nines is not difficult to achieve. There is only one provider of hardware that guarantees five nines uptime using a non-proprietory OS ... take a guess: its a Windows OS.
Finally, in terms of productivity applications and available skills and/or training, Linux can't touch Windows. They are literally hundreds or applications for every purpose out there that are smooth and polished and do what a business wants. More importantly, you'll easily find staff that are experienced with that package, and that's a huge cost saving.
So yes, Linux is free and cheap and all that, and has tons of applications, and can do amazing stuff. But it doesn't do it out of the box, few people know the desktop environment or the applications, and it takes a less common skillset to configure, administer, maintain and develop in a Linux environment. All of which push up the long term TCO, and allow you to make a very valid cost comparison with Windows.
This sounds largely accurate. I was enjoying the article a lot until the following sentence sent a chill down my spine:
Microsoft are on (recent) record saying that the future they forsee is free hardware with licensed software and content.
Windows has virtual desktops. The support has been provided at OS level since Windows NT ; you just need to get a utility to use them. Try Virtuawin, its even OSS.
The direct consequence of forks in C is autoconf.
Unfortunately "one size fits all" solutions seldom work. My SO worked in the buying department of a large retail group, who decided to start clearing out e-mail over 60 days old. Problem is the department has to place orders on suppliers 6 to 9 months before delivery. By the time delivery rolls around, most tracability is lost, including date estimates which suppliers swear they didn't commit to.
Now all of this can be handled by printing out the e-mails (ack!), but you sort-of need to know to do this before the delete everything, right? Go figure.