You are talking mostly bollocks, probably because you don't program using the Windows API
Anyway, PThreads is better. The reason is that Win32 gives you a fixed set of synchronization primitives. If you can solve your problem with those primitives. they work great. If you can't, you are completely stuck.
And PThreads also gives you a fixed set of primitives. In some respects they are more powerful, in others they are weaker. This is a bullshit strawman.
For example, it used to be that a socket handle was not a synchronization object, so you couldn't integrate select() calls with other synchronization primitives.
WTF?
select() has nothing to do with synchronization. Although it does have something to do with scheduling.
select() can't wait on "synchronization primitives" under *nix. Really. Try man select. It works with FDs, only.
select() is not a core function of the Windows API. It is part of Winsock, which uses lower level scheduling primitives.
Finally, if you want to do asynchronous development with Windows you use Async IO, not select. Async IO is built on top of Events, which are synchronization primitives.
That brings me to the next point: in Unix there is no wait to wait on multiple synchronization primitives (as opposed to FDs) at once, and only a few primitives support a timed wait. In Windows you have WaitForMultipleObjectsEx. Look it up.
Let me be clear on the difference: in Windows the scheduler API for waiting on IO and synchronization primitives is fully integrated - you can wait on any combination of IO and sync objects in the same Wait call. You must of course be using Windows Async IO which uses Events rather than FDs as the waitable object. Under *nix you can wait for multiple condition variables, or multiple file descriptors, or a single mutex / thread / process. There is no way to link an FD to a condition variable.
PThreads gives you condition variables. They are harder to program, but once you understand them, you can use them to synchronize on absolutely anything. You aren't dependent on the OS to have foreseen your special needs and provided special synchronization primitives to meet them.
In Windows you have Mutexes, Events and Semaphores. Events alone are sufficient to provide almost identical functionality to condition variables. You may have missed that memo.
If you really want the Win32 model, it is easy enough to build it on top of PThreads, but there is no way to build PThreads on top of Win32.
Cough. Bullshit. Cough. Read Porting of Win32 API WaitFor to Solaris Platform to get a clue. It is possible to build Pthreads on top of Win32, and vice versa. Neither emulation is particularly efficient though.
The complaint about lost signals in PThreads means that the author is using them incorrectly.
The complaint about weakness in the Win32 scheduling API means that the author is using it incorrectly.
ROI. Wonderful buzzword, usually meaning "I don't have a clue what I'm talking about but I want to sound impressive".
Put simply you can't earn a return on a cost, only on an asset. Investment doesn't mean "put money into it", it means capital expenditure to acquire an asset. You invest on the basis of an expected return at a given level of risk associated with the asset. ROI is one of the measures that can be used to assess the attractiveness of the investment.
These are definitions. You can't substitute definitions of "return" and "investment" from other domains into the phrase "return on investment" and expect the calculation to produce a meaningful answer.
Another definition: risk is deviation from the expected outcome. In order to assess risk you need to know the potential risk events, their frequency and their magnitude. Then you can manage the risk by protecting against events, insuring, or doing nothing and hoping your business can take the losses.
Go and read some books on risk management and learn the appropriate measures of risk. You can probably start with the Wikipedia. Don't try and fudge it by using investment management measures, which are inappropriate.
You can't make money by improving your security. You can reduce costs (associated with your existing security system) and you can reduce the frequency and/or magnitude of risk events. Of course if you haven't identified the risks in the first place you don't know if your security is going to be effective, or how much those risk events would cost, or if insurance is a better option than prevention.
Yeah. Either this guy has some strange understanding of contract law, or Australia as a whole does.
For a contract to be valid, both parties have to understand it and voluntarily agree to it. The "understand it" bit is important -- a contract where the two parties aren't actually agreeing to the same thing (due to a partial or complete misunderstanding) is not necessarily valid.
Up to the point where there is a dispute over understanding, the subjective interpretation of the contract is what the court will take into account. If the meaning is disputed, the court will attempt to determine an objective interpretation according to the "reasonable man" hypothesis.
I'm pretty sure that I know what a "reasonable man" would understand on reading the BSD license. And it's not some weird grammatical corner-case that the article tries to imply.
In civil litigation it is the court's job to resolve problems, not to play Game Master as screw the players by using a selective interpretation of wording. The intentions of the parties are important in the court's consideration. For example, if project X releases source code under the BSD license and says in a FAQ on it's web page "you can do pretty much what you like, even use this in commercial software", then the judgement is going to be pretty much straightforward.
In fact, giving the "common wisdom" about the BSD license, a copyright holder who releases a work under the BSD license will have some trouble proving to the court how they misunderstood the license and released their stuff under it and now want to sue someone...
Yes, but a failure of hardware integrity does not necessary constitute a break of the system.
There are two important cross-checks that are being ignored by this posing.
First, a terminal that does not work will not be used. These are merchant point-of-sale devices, not ATM PIN pads. They are operated in the presence of both the customer and (a representative of) the merchant. As soon as the teller realises that the terminal isn't authorising transactions a fault will be reported to a supervisor, and the terminal will not be used until it is fixed.
Second, assuming that a really thorough job has been done of replacing the terminal innards, and it reports to the till that the transaction is successful, there will still be a reconciliation problem at the end of the day. And it will point very clearly to all EMV transactions at a particular till point.
So even if you can pull off this attack, it will be detected in a short time.
Security is a trade-off. The objective of EMV and other payment schemes is to reduce fraud but still be usable and cost effective. There are many ways to design a more secure system, but they usually involve (1) unacceptably high transaction latency (customers are a lot more impatient than you may think), (2) high costs to the customer which will affect uptake, or (3) high costs to the banks in terms of migrating legacy systems.
Banks, as you may have noticed, like money;) So right now they have calculated that the level of fraud that will remain under EMV is lower than the cost of migrating their legacy systems (and, importantly, their customers).
This is good advice, especially the bit about "non-business-critical components".
I'm going through the process of getting company approval to release a component as Open Source, so I'll add my 2c for anyone who finds themselves in this position.
First, drag your sorry brain out of the technical trenches and understand how your business creates value. You have to understand that before your can claim that any given bit of code is or is not valuable.
Second, focus your efforts on bits of code that you can argue are not Intellectual Property; that is, they do not provide a special value or advantage to your company that would be lost by them being generally available to the public.
Third, in justifying an Open Source release of the code concentrate on the benefits of contributing the code, and the costs of not contributing the code. Your best argument will be maintenance costs -- if the code doesn't provide specific competitive value then making it open source adds potential maintainers.
PR is not a good argument. Just accept that you don't understand PR, or your company's PR strategy, and that your company doesn't give a damn about what the FLOSS community thinks about it; and even it did it wouldn't use contributing patches as a way to manage PR with the community.
Finally, do more than your company expects of you. If you are genuinely concerned about the FLOSS community then you'll be happy to contribute a bit of your own time, not just your company's time & money, right? So do some improvements of your own, in your own time. Then take those to your company and explain that they're useful to the company, but not of specific competitive importance, and that you did them yourself, you didn't do them on company time, and you'd personally like to contribute them to the community but you can't because of your contract. Now you have a strong moral argument.
Frameworks aren't all they're cracked up to be
on
The Case for OpenID
·
· Score: 1
The thing with frameworks... is that over time implementation costs increase, and interoperability decreases, as you add more concrete stuff within the framework. They give the illusion of value.
The attacks described are against the PIN Translation function, not PIN Verification.
PINs, as you will know, must be formatted before encryption. ANSI X9.8 and ISO 9564 provide standards for PIN formats. You should also know that in its passage across a network, a PIN goes through several zones, and is changed not only from one encryption key to another, but also from one format to another, according to the zone.
The attacks exploit the fact that you can change the PIN's format, in particular the ability to change the format to a legacy one that does not include the user's account number or random data along with the PIN. In such a format there is only one possible ciphertext for every clear PIN (under a given key); or 10,000 ciphertexts for all possible 5 digit PINs.
So assuming you have those 10,000 ciphertexts and access to an HSM that will reformat the PIN to a format that excludes the account number, you can just look at the encrypted PIN and know which clear value it must correspond to. This is much like guessing hashed passwords (and in this case the password can only be 5 digits!).
You can read the paper to understand how they get those 10,000 ciphertexts... it's quite clever;)
Actually it has surfaced before. These researchers have extended attacks that were described in 2003, which in turn extended earlier attacks. Even before that ANSI & ISO issued several updates to PIN encryption standards to protect against known weaknesses.
The oldest standards for PIN encryption used the naive approach of padding the PIN and encrypting it. For a 5 digit PIN this gives only 10,000 possible ciphertexts per key. The attacks describes by the Israeli researchers target this format.
Better standards have been available since at least 1991. They combine the PIN with the account number before encryption, giving 10,000 possible ciphertexts per key per account. This is harder to attack. Even more recent standards (from 2001) include random data or a transaction counter before encryption, making each ciphertext unique. There are also key management standards dating back to the 1990s that use a unique key per transaction, which defeats most if not all of these attacks.
The idea that these attacks are new and the system was thought to be unassailable before is just attention seeking.
No, it's not. Translators of this nature are used in numerous crypto systems.
In any system you have to balance risk with practicality. The risk in this case (a symmetric system) is protocol insecurities and protecting the physical security of several processing points. The practical value (besides not having to change a system that has worked for decades) is that symmetric crypto is cheap to implement in hardware (asymmetric has been very expensive until recently) and puts less demands on communication (number and size of messages, which affects the amount of time you wait for the transaction to be verified).
In an asymmetric system you still have the risk of protocol insecurities, but less processing points to protect. You add protocol insecurity risk (because you must use a PKI to distribute keys), and until recently you would have added cost (asymmetric crypto is either slow or expensive).
This is not, as the article may imply, an attack on the crypto infrastructure. It is an attack on a particular weak method of PIN encryption combined with an attack on a legacy support function that allows you not only to translate the encryption of a PIN, but reformat it (i.e. change the method of encryption) as well. If banks stopped using encryption methods for PINs that are known to be insecure, this problem would go away.
I was replying to a parent comment that misinterpreted Marx. Religion, according to Marx, is a symptom of social and economic problems; it develops as a social response to and defense against those problems, as a means to console its adherents. Then, according to Marx, religion can be abused by those in positions of authority so that belief and doctrine is used as an explanation or justification for the social and economic problems, as a result of which the population accepts those problems rather than trying to correct them. In this way, according to Marx, religion is used to oppress people -- they allow religious doctrine to control their destiny rather than tackling the social and economic problems facing them.
So the definition of religion, according to Marx, includes oppression.
One of the criticisms of Marx' views is that spirituality is fundamental to religion, and spirituality deals with the search for a higher truth.
Erm, that was not my definition of oppression (hence the comment about "according to Marx").
That said, at the core of any institutionalized religion you will find dogma. Dogma is the authoratative and established belief or doctrine of any religion or ideology. In order to accept and practice the religion you must submit to the dogmata and in respect of those dogmata give up personal control.
The fact that the government of the United States was not established by Christians or on Christian principles does not detract from the fact that the original settlers of the lands now forming the United States were Christians coming from denominations that class as "fundamentalist", nor that the population of the United States - as a direct result of its original settlers - is primarily (80%) Christian.
Perhaps I should have said "settled" or "colonized" rather than "founded", or maybe "the lands that would become known as the United States". Not all of us measure our national history by the formation of the current system of government.
Marx meant it as a means to tame an oppressed class "Suffering in this life guarantees you Paradise in the afterlife!".
No. Marx said that religion is a social defense mechansim, the expression of problems in society, and develops based on the material and economic realities in a given society. Authorities can use religion as a means to console an oppressed class. Marx also said that people should transcend religion and take control of their own destiny.
We can hardly call the american middle-class "oppressed" in any way.
If you have surrendered your capacity to take decisions, to think for yourself, and to control your own destiny, then you are oppressed (according to Marx and others). Religion is, by this definition, oppression.
Actually, come to think of it, I have no idea how come religion (specifically, christianism) is so powerful in such a developped country as the USA...
Perhaps it has something to do with Spain starting the colonization of the Americas by imposing Catholicism on all natives and immigrants. Or maybe it was the pilgrims, puritans, quakers, and lutherans that followed them, avoiding religious persecution in Europe. Or maybe you should just read about the Eurpoean colonization of the Americas to understand why the USA was founded by a bunch of Christian fundamentalists.
I think you've identified on most of the major areas that cause portability problems, with the possible exception of endianness. Since I actively maintain software under Windows, Linux and Solaris, let me add some comments:
If you're developing a GUI application then a decent GUI library will handle most of your problems. Libraries like wxWidgets and QT provide cross-platform GUI widgets as well as thread creation and synchronization primitives. They usually also provide socket abstractions, or you can use another cross-platform library like ACE.
Things get more hairy when you enter the realm of server applications and high performance. Software written for *nix is pretty much straightforwardly portable to Windows, but not the reverse.
The difference is in the schedulers, which affects processes, threads, synchronization, and blocking and non-blocking IO. In a nutshell the Windows scheduler deals with threads and not processes, is a fair scheduler, and a thread can block on multiple conditions simultaneously.
That should be a lot to digest, so let me try to explain that statement and its implications:
First a disclaimer: I am going to talk about *nix in generalisations, because both Linux and Solaris support a variety of schedulers and the default scheduler can change between versions, and userland and kernel threading libraries behave very differently.
ONE: The Windows scheduler schedules threads. Processes are merely containers for threads and their address space, access tokens, etc. Processes are not scheduled. This means that a multithreaded process on Windows has fundamentally different time sharing characteristics to a *nix application. The characteristics would be most similar to a multiprocess application in the *nix world. Most *nix schedulers I have encountered schedule processes first, then schedule threads within the process.
TWO: The Windows scheduler is "fair" -- it is a multilevel queue with round-robin at each level. Threads with a higher priority will always preempt those of a lower priority, and priority elevation is used to prevent starvation.
A number of *nix schedulers use a n adaptive algorithm that favours historically busy processes. This means that a producer-consumer approach may work well on a Windows system, but experience high latency on *nix (note: not reduced throughput under load, but increased latency). Such an approach can work on *nix, but must be implemented differently.
Both Linux and Solaris can be set to use round-robin schedulers (e.g. Solaris's real-time class process), but this can degrade overall system performance.
THREE: A thread can block on multiple objects simultaneously. I said "conditions" before, but I'd prefer to get more specific. A Windows thread can wait for the end of another thread or process, a mutex, and event (like a condition in *nix), an IO operation, a semaphore, a timer, and a couple of others. The thread can also block under any one, or all, of a number of objects are in the signalled state.
Compare that to *nix where you can wait on one of anything except for IO, where you can use select (or poll or dev/poll or kqueue) to wait on multiple non-blocking file descriptors. kqueue is a little more functional, but to my knowledge still doesn't support synchronization objects. If you are using SysV semaphores you can wait for multiple semaphores to be signalled.
This has huge implications for application design. On Windows you can have a consumer thread wait on multiple producer threads using one mutex per consumer to control synchronization. All threads can be awoken from any wait state by a global event to inform them of reconfiguration, shutdown, etc. This is quite trivial, and is a straightforward and easily understood design.
Move the same design to a *nix platform and you have problems. First your consumer thread can't wait on multiple producers without some radical changes (use could pipes rather tha
I have worked with parsers and compilers in the past, but most of my time now is working with crypto;) That said, I'm an SE by practice although a CS by qualification.
In my line of work SE and CS come together when I get to protocols and algorithms. Formal grammars are essential in describing protocols (think BNF) and modeling for robustness. As an example, getting FIPS certification for crypto hardware requires submitting a finite state model of the firmware.
I have a poor grounding in graph theory and linear algebra (I just apply the crypto algorithms) but have found it useful in optimisation of algorithms.
Statistics, IMHO, is the bridge between theory and reality when it comes to performance. A constant time algorithm can really suck if the constant is large enough;) Sometimes it is better to use a slow-but-simple algorithm (easy to develop, debug & maintain) and optimise special but common cases, rather than using a complex but higher performance algorithm. Statistics can help you to understand the performance bounds of the application, how it will scale in the real world, etc. It also helps you to understand how numbers can lie, and the difference between good sampling and bad sampling (this microbenchmarks).
None of it is as much a cornerstone of good coding as lin alg IMHO, but they're all really really nice to have sometimes.
...but then CS isn't about good coding, it's about taking over the world (y'know, "science"). IMHO there is nothing better for good coding than to slow down, do a tiny thing at a time, and wonder what path execution will follow when your assumptions are wrong.
Developers need to experience a benefit from the practices they are asked to adopt, or they will have no internal motivation to adopt them. In that case you are forced to use external motivators (rewards or punishment) which are never as effective.
There are only two reasons to introduce a practice: (1) to improve productivity; and/or (2) to CYA (cover your ass). Any practice that doesn't do one of those is worthless.
Practices that improve productivity should (and generally do) appeal to developers. Such practices usually involve working smarter rather than harder, isolating developers from mistakes or inconvenience caused by other developers, and taking care to reduce mistakes early in the development cycle (so less frustrating debugging at integration time). Take the time to ensure that developers understand what the practice will do for them, and they'll have an intrinsic motivation to follow it.
Practices that CYA are more difficult to implement. These represent business concern about liability that course arise from the way things are being done. That could involve labour issues (developers have been under pressure to work overtime), intellectual property (someone is copying GPL code into the code base), or following industry norms so that you can't be sued for negligence.
Where industry norms differ from the practices that improve productivity you'll need to educate developers and provide some external motivation (usually punishment) to ensure compliance.
Start by making sure you understand the distinction between Computer Science and its related disciplines, and that this is a CS course. Read the overview report from the ACM Curricula Recommendations..
It is apparent from the ACM's recommendations (amongst others) that a lot of mathematics traditionally covered at universities(such as calculus) is not strongly related to Computer Science. That said, there are many applications of computing that require strong skills in these areas (scientific computing and cryptography for example) so they are not a bad option.
Important numerical and logical fundamentals that support the learning and use of undergraduate Computer Science include:
Basic computing theory (formal grammars and finite automata). Understanding the qualities and use of state machines and formal grammars is essential in many fields of computer science including algorithm and protocol design, modeling robust systems, and creating parsers (e.g. for domain specific languages). It is also necessary to understand the halting problem and turing theory. Most of the theory requires the use of proof by induction or construction, which (in my experience) are the most common proof techniques in CS.
First-order logic (predicate calculus). Also exceptionally valuable in the development of data structures and algorithms, and for communicating between domains.
Graph theory. Understanding complexity, efficiency and optimisation in many aspects of CS (including compilers, algorithms, networks, data structures, etc) requires an understand of graph theory.
Statistics. You will use it in most forms of analysis, at least to verify that a real-world realisation matches the predictions of a theory. Also valuable for performance analysis and optimisation to determine performance distribution and bounds.
Single Sign-On and Trusted Third Parties don't solve all your problems. As the original poster said, these include database passwords, and will probably include things like passwords for network devices (routers, firewalls, switch management interfaces). These require a password management solution, not SSO or TTP.
There are a couple of enterprise password management products available that can provide ACL controlled access to passwords. They are mostly expensive, and some are inflexible.
A cheaper solution is to use something like Password Safe with a network-accessible database. Identify a limited set of users and share the safe password between them. Then keep that password locked in a dual-access-only safe or vault for disaster recovery.
If you have different classes of users that only need a subset of passwords (network admins, DBAs, account system admins) then use one password safe database per class. Obviously each database will have a unique password;)
For more complex environments where you need the flexibility of ACLs, you'll have to get an enterprise product.
Yeah, because the moment I do know my (hypothetical) kid is breaking the law, it becomes my legal obligation to (a) report the crime, and (b) take action to prevent my property from being used in the commission of future crimes of this sort. So unless I ground the kid or take appropriate action to "reeducate" him/her/it not to repeat the crime, I share in the criminal liability.
Real humans make mistakes. The best developers may be less likely to make big mistakes and introduce logic bugs, but even they will commit simple errors from time to time. So there is always a need for review, be it human or automaton.
It is not easy to find "the best" developers, or to distinguish them from above average developers (and average isn't very good). It was recently shown that "the best" people in their field consistently rate themselves lower than the set of people who are just below them -- essentially they have reached a level of maturity and knowledge to understand their weaknesses.
It takes a good developer at least a month to become familiar with a new environment (the policies and procedures, "how things are done here", basic navigation of the source tree(s) and tools), for a simple environment. In an environment dominated by domain specific knowledge or industry standards it can take 4 to 6 months to become productive. That's one heck of an investment, and to then decide "this guy ain't good enough" is not justifiable in business terms.
Further, "the best" developers are also the most mobile, and the most expensive. After you've invested in getting them familiar with your environment, they are the most likely to leave.
So instead you consider finding a very small number of "the best" developers, and staffing up on "average" developers. Then you invest in quality assurance, ideally guided by "the best" developers, to ensure that everyone is keeping the standard.
The benefit of tools like this is that they are not responsive to arguments or pressure or transient underperformance. You can always argue with a human reviewer that the code is right and the reviewer is wrong (unless the reviewer has a set of cast-in-stone laws to be checked, which makes the reviewer simply a fallable automaton). Managers can always pressure reviewers to be more lenient because of time pressue. Reviewers can have an "off day" and miss potentially large bugs. These tools don't catch everything -- they aren't a replacement for competent human review -- but they do catch and prevent large groups of trivial, avoidable and easily missed errors.
The audio CD format uses error correcting codes (See Reed-Solomon_error_correction). I don't believe CDR data formats do (but I could be wrong about that). Anyway, it would appear that scratches are more likely to cause tracking errors than non-reflective marks, which makes it easier for the drive to access and error correcting codes and reconstruct the damage.
The result is a CIRC that can completely correct error bursts up to 4000 bits, or about 2.5 mm on the disc surface. This code is so strong that most CD playback errors are almost certainly caused by tracking errors that cause the laser to jump track, not by uncorrectable error bursts
Witch hunts since the colonisation of North America have mostly been about subjugation of women.
Is she trying to have her own opinions with her husband's permission? Must be a witch. Husband sleeping with a younger, prettier woman? Couldn't be him! She must be a witch. Woman trying to read or get an edumacation? Unnatural I tell you! Must be a witch! Widow without a husband or children being an economic burden on the town? Well she must be a witch -- Godly people have children you know.
I think you have an important point here: national ID numbers can be abused in private hands because they provide a convenient universal identifier for you. So corporations can now share and correlate data about you where, without an ID number, they would have a much harder time matching up the records they all hold to get "complete" knowledge of a particular individual.
In my country (which has national ID) its use is somewhat different. You can't get a bank account, a cell phone, a landline, or just about any arrears-payment service without disclosing your ID number. Nor can you open a credit account with a retail store. And you can't even rent property without providing the landlord with your ID number (unless you deal with really dodgy landlords) because of responsibilities placed on landlords to know their tenants in order to reduce crime. There are no effective data protection laws restricting what can be done with that information by service providers.
I've always had the feeling that national ID should be "your account number with the government". It allows you access to government services, and you have to make payments to the government for that (tax). So in the same way as you wouldn't give your telephone account number to the grocer, your national ID is something between you and the government only.
As soon as you have to disclose your ID number to anyone, it is no longer secret. For example, contracts of transfer for houses are usually lodged in a deeds office, and are subject to public scrutiny. If you do a little bit of looking, you'll find examples that are applicable to your own nation.
All physical documents are easy to fake, in time. This is the reason that most nations replace their paper money and coins ever 8 years or so. But some documents, like drivers licenses and IDs, are meant to last a lot longer... yet they have weaker security properties than money!
The closest thing we can make right now to an "unfakable" ID document is a smart card with NO information printed on it. The only way to use it is by insertion into a reader which will verify a signature (issued by a trusted registry, probably the government) over a name and image, and then display the name and image.
Slashdot Mirror
You are talking mostly bollocks, probably because you don't program using the Windows API
And PThreads also gives you a fixed set of primitives. In some respects they are more powerful, in others they are weaker. This is a bullshit strawman.
WTF?
That brings me to the next point: in Unix there is no wait to wait on multiple synchronization primitives (as opposed to FDs) at once, and only a few primitives support a timed wait. In Windows you have WaitForMultipleObjectsEx. Look it up.
Let me be clear on the difference: in Windows the scheduler API for waiting on IO and synchronization primitives is fully integrated - you can wait on any combination of IO and sync objects in the same Wait call. You must of course be using Windows Async IO which uses Events rather than FDs as the waitable object. Under *nix you can wait for multiple condition variables, or multiple file descriptors, or a single mutex / thread / process. There is no way to link an FD to a condition variable.
In Windows you have Mutexes, Events and Semaphores. Events alone are sufficient to provide almost identical functionality to condition variables. You may have missed that memo.
I say "almost identical" because the underlying scheduler behaviour is slightly different, which makes it very difficult to perfectly emulate Pthreads on Win32. Read Strategies for Implementing POSIX Condition Variables on Win32.
Cough. Bullshit. Cough. Read Porting of Win32 API WaitFor to Solaris Platform to get a clue. It is possible to build Pthreads on top of Win32, and vice versa. Neither emulation is particularly efficient though.
The complaint about weakness in the Win32 scheduling API means that the author is using it incorrectly.
ROI. Wonderful buzzword, usually meaning "I don't have a clue what I'm talking about but I want to sound impressive".
Put simply you can't earn a return on a cost, only on an asset. Investment doesn't mean "put money into it", it means capital expenditure to acquire an asset. You invest on the basis of an expected return at a given level of risk associated with the asset. ROI is one of the measures that can be used to assess the attractiveness of the investment.
These are definitions. You can't substitute definitions of "return" and "investment" from other domains into the phrase "return on investment" and expect the calculation to produce a meaningful answer.
Another definition: risk is deviation from the expected outcome. In order to assess risk you need to know the potential risk events, their frequency and their magnitude. Then you can manage the risk by protecting against events, insuring, or doing nothing and hoping your business can take the losses.
Go and read some books on risk management and learn the appropriate measures of risk. You can probably start with the Wikipedia. Don't try and fudge it by using investment management measures, which are inappropriate.
You can't make money by improving your security. You can reduce costs (associated with your existing security system) and you can reduce the frequency and/or magnitude of risk events. Of course if you haven't identified the risks in the first place you don't know if your security is going to be effective, or how much those risk events would cost, or if insurance is a better option than prevention.
Yeah. Either this guy has some strange understanding of contract law, or Australia as a whole does.
For a contract to be valid, both parties have to understand it and voluntarily agree to it. The "understand it" bit is important -- a contract where the two parties aren't actually agreeing to the same thing (due to a partial or complete misunderstanding) is not necessarily valid.
Up to the point where there is a dispute over understanding, the subjective interpretation of the contract is what the court will take into account. If the meaning is disputed, the court will attempt to determine an objective interpretation according to the "reasonable man" hypothesis.
I'm pretty sure that I know what a "reasonable man" would understand on reading the BSD license. And it's not some weird grammatical corner-case that the article tries to imply.
In civil litigation it is the court's job to resolve problems, not to play Game Master as screw the players by using a selective interpretation of wording. The intentions of the parties are important in the court's consideration. For example, if project X releases source code under the BSD license and says in a FAQ on it's web page "you can do pretty much what you like, even use this in commercial software", then the judgement is going to be pretty much straightforward.
In fact, giving the "common wisdom" about the BSD license, a copyright holder who releases a work under the BSD license will have some trouble proving to the court how they misunderstood the license and released their stuff under it and now want to sue someone ...
Yes, but a failure of hardware integrity does not necessary constitute a break of the system.
There are two important cross-checks that are being ignored by this posing.
First, a terminal that does not work will not be used. These are merchant point-of-sale devices, not ATM PIN pads. They are operated in the presence of both the customer and (a representative of) the merchant. As soon as the teller realises that the terminal isn't authorising transactions a fault will be reported to a supervisor, and the terminal will not be used until it is fixed.
Second, assuming that a really thorough job has been done of replacing the terminal innards, and it reports to the till that the transaction is successful, there will still be a reconciliation problem at the end of the day. And it will point very clearly to all EMV transactions at a particular till point.
So even if you can pull off this attack, it will be detected in a short time.
Security is a trade-off. The objective of EMV and other payment schemes is to reduce fraud but still be usable and cost effective. There are many ways to design a more secure system, but they usually involve (1) unacceptably high transaction latency (customers are a lot more impatient than you may think), (2) high costs to the customer which will affect uptake, or (3) high costs to the banks in terms of migrating legacy systems.
Banks, as you may have noticed, like money ;) So right now they have calculated that the level of fraud that will remain under EMV is lower than the cost of migrating their legacy systems (and, importantly, their customers).
This is good advice, especially the bit about "non-business-critical components".
I'm going through the process of getting company approval to release a component as Open Source, so I'll add my 2c for anyone who finds themselves in this position.
First, drag your sorry brain out of the technical trenches and understand how your business creates value. You have to understand that before your can claim that any given bit of code is or is not valuable.
Second, focus your efforts on bits of code that you can argue are not Intellectual Property; that is, they do not provide a special value or advantage to your company that would be lost by them being generally available to the public.
Third, in justifying an Open Source release of the code concentrate on the benefits of contributing the code, and the costs of not contributing the code. Your best argument will be maintenance costs -- if the code doesn't provide specific competitive value then making it open source adds potential maintainers.
PR is not a good argument. Just accept that you don't understand PR, or your company's PR strategy, and that your company doesn't give a damn about what the FLOSS community thinks about it; and even it did it wouldn't use contributing patches as a way to manage PR with the community.
Finally, do more than your company expects of you. If you are genuinely concerned about the FLOSS community then you'll be happy to contribute a bit of your own time, not just your company's time & money, right? So do some improvements of your own, in your own time. Then take those to your company and explain that they're useful to the company, but not of specific competitive importance, and that you did them yourself, you didn't do them on company time, and you'd personally like to contribute them to the community but you can't because of your contract. Now you have a strong moral argument.
The thing with frameworks ... is that over time implementation costs increase, and interoperability decreases, as you add more concrete stuff within the framework. They give the illusion of value.
The attacks described are against the PIN Translation function, not PIN Verification.
PINs, as you will know, must be formatted before encryption. ANSI X9.8 and ISO 9564 provide standards for PIN formats. You should also know that in its passage across a network, a PIN goes through several zones, and is changed not only from one encryption key to another, but also from one format to another, according to the zone.
The attacks exploit the fact that you can change the PIN's format, in particular the ability to change the format to a legacy one that does not include the user's account number or random data along with the PIN. In such a format there is only one possible ciphertext for every clear PIN (under a given key); or 10,000 ciphertexts for all possible 5 digit PINs.
So assuming you have those 10,000 ciphertexts and access to an HSM that will reformat the PIN to a format that excludes the account number, you can just look at the encrypted PIN and know which clear value it must correspond to. This is much like guessing hashed passwords (and in this case the password can only be 5 digits!).
You can read the paper to understand how they get those 10,000 ciphertexts ... it's quite clever ;)
Actually it has surfaced before. These researchers have extended attacks that were described in 2003, which in turn extended earlier attacks. Even before that ANSI & ISO issued several updates to PIN encryption standards to protect against known weaknesses.
The oldest standards for PIN encryption used the naive approach of padding the PIN and encrypting it. For a 5 digit PIN this gives only 10,000 possible ciphertexts per key. The attacks describes by the Israeli researchers target this format.
Better standards have been available since at least 1991. They combine the PIN with the account number before encryption, giving 10,000 possible ciphertexts per key per account. This is harder to attack. Even more recent standards (from 2001) include random data or a transaction counter before encryption, making each ciphertext unique. There are also key management standards dating back to the 1990s that use a unique key per transaction, which defeats most if not all of these attacks.
The idea that these attacks are new and the system was thought to be unassailable before is just attention seeking.
No, it's not. Translators of this nature are used in numerous crypto systems.
In any system you have to balance risk with practicality. The risk in this case (a symmetric system) is protocol insecurities and protecting the physical security of several processing points. The practical value (besides not having to change a system that has worked for decades) is that symmetric crypto is cheap to implement in hardware (asymmetric has been very expensive until recently) and puts less demands on communication (number and size of messages, which affects the amount of time you wait for the transaction to be verified).
In an asymmetric system you still have the risk of protocol insecurities, but less processing points to protect. You add protocol insecurity risk (because you must use a PKI to distribute keys), and until recently you would have added cost (asymmetric crypto is either slow or expensive).
This is not, as the article may imply, an attack on the crypto infrastructure. It is an attack on a particular weak method of PIN encryption combined with an attack on a legacy support function that allows you not only to translate the encryption of a PIN, but reformat it (i.e. change the method of encryption) as well. If banks stopped using encryption methods for PINs that are known to be insecure, this problem would go away.
I was replying to a parent comment that misinterpreted Marx. Religion, according to Marx, is a symptom of social and economic problems; it develops as a social response to and defense against those problems, as a means to console its adherents. Then, according to Marx, religion can be abused by those in positions of authority so that belief and doctrine is used as an explanation or justification for the social and economic problems, as a result of which the population accepts those problems rather than trying to correct them. In this way, according to Marx, religion is used to oppress people -- they allow religious doctrine to control their destiny rather than tackling the social and economic problems facing them.
So the definition of religion, according to Marx, includes oppression.
One of the criticisms of Marx' views is that spirituality is fundamental to religion, and spirituality deals with the search for a higher truth.
Erm, that was not my definition of oppression (hence the comment about "according to Marx").
That said, at the core of any institutionalized religion you will find dogma. Dogma is the authoratative and established belief or doctrine of any religion or ideology. In order to accept and practice the religion you must submit to the dogmata and in respect of those dogmata give up personal control.
The fact that the government of the United States was not established by Christians or on Christian principles does not detract from the fact that the original settlers of the lands now forming the United States were Christians coming from denominations that class as "fundamentalist", nor that the population of the United States - as a direct result of its original settlers - is primarily (80%) Christian.
Perhaps I should have said "settled" or "colonized" rather than "founded", or maybe "the lands that would become known as the United States". Not all of us measure our national history by the formation of the current system of government.
No. Marx said that religion is a social defense mechansim, the expression of problems in society, and develops based on the material and economic realities in a given society. Authorities can use religion as a means to console an oppressed class. Marx also said that people should transcend religion and take control of their own destiny.
If you have surrendered your capacity to take decisions, to think for yourself, and to control your own destiny, then you are oppressed (according to Marx and others). Religion is, by this definition, oppression.
Perhaps it has something to do with Spain starting the colonization of the Americas by imposing Catholicism on all natives and immigrants. Or maybe it was the pilgrims, puritans, quakers, and lutherans that followed them, avoiding religious persecution in Europe. Or maybe you should just read about the Eurpoean colonization of the Americas to understand why the USA was founded by a bunch of Christian fundamentalists.
I think you've identified on most of the major areas that cause portability problems, with the possible exception of endianness. Since I actively maintain software under Windows, Linux and Solaris, let me add some comments:
If you're developing a GUI application then a decent GUI library will handle most of your problems. Libraries like wxWidgets and QT provide cross-platform GUI widgets as well as thread creation and synchronization primitives. They usually also provide socket abstractions, or you can use another cross-platform library like ACE.
Things get more hairy when you enter the realm of server applications and high performance. Software written for *nix is pretty much straightforwardly portable to Windows, but not the reverse.
The difference is in the schedulers, which affects processes, threads, synchronization, and blocking and non-blocking IO. In a nutshell the Windows scheduler deals with threads and not processes, is a fair scheduler, and a thread can block on multiple conditions simultaneously.
That should be a lot to digest, so let me try to explain that statement and its implications:
First a disclaimer: I am going to talk about *nix in generalisations, because both Linux and Solaris support a variety of schedulers and the default scheduler can change between versions, and userland and kernel threading libraries behave very differently.
ONE: The Windows scheduler schedules threads. Processes are merely containers for threads and their address space, access tokens, etc. Processes are not scheduled. This means that a multithreaded process on Windows has fundamentally different time sharing characteristics to a *nix application. The characteristics would be most similar to a multiprocess application in the *nix world. Most *nix schedulers I have encountered schedule processes first, then schedule threads within the process.
TWO: The Windows scheduler is "fair" -- it is a multilevel queue with round-robin at each level. Threads with a higher priority will always preempt those of a lower priority, and priority elevation is used to prevent starvation.
A number of *nix schedulers use a n adaptive algorithm that favours historically busy processes. This means that a producer-consumer approach may work well on a Windows system, but experience high latency on *nix (note: not reduced throughput under load, but increased latency). Such an approach can work on *nix, but must be implemented differently.
Both Linux and Solaris can be set to use round-robin schedulers (e.g. Solaris's real-time class process), but this can degrade overall system performance.
THREE: A thread can block on multiple objects simultaneously. I said "conditions" before, but I'd prefer to get more specific. A Windows thread can wait for the end of another thread or process, a mutex, and event (like a condition in *nix), an IO operation, a semaphore, a timer, and a couple of others. The thread can also block under any one, or all, of a number of objects are in the signalled state.
Compare that to *nix where you can wait on one of anything except for IO, where you can use select (or poll or dev/poll or kqueue) to wait on multiple non-blocking file descriptors. kqueue is a little more functional, but to my knowledge still doesn't support synchronization objects. If you are using SysV semaphores you can wait for multiple semaphores to be signalled.
This has huge implications for application design. On Windows you can have a consumer thread wait on multiple producer threads using one mutex per consumer to control synchronization. All threads can be awoken from any wait state by a global event to inform them of reconfiguration, shutdown, etc. This is quite trivial, and is a straightforward and easily understood design.
Move the same design to a *nix platform and you have problems. First your consumer thread can't wait on multiple producers without some radical changes (use could pipes rather tha
I have worked with parsers and compilers in the past, but most of my time now is working with crypto ;) That said, I'm an SE by practice although a CS by qualification.
In my line of work SE and CS come together when I get to protocols and algorithms. Formal grammars are essential in describing protocols (think BNF) and modeling for robustness. As an example, getting FIPS certification for crypto hardware requires submitting a finite state model of the firmware.
I have a poor grounding in graph theory and linear algebra (I just apply the crypto algorithms) but have found it useful in optimisation of algorithms.
Statistics, IMHO, is the bridge between theory and reality when it comes to performance. A constant time algorithm can really suck if the constant is large enough ;) Sometimes it is better to use a slow-but-simple algorithm (easy to develop, debug & maintain) and optimise special but common cases, rather than using a complex but higher performance algorithm. Statistics can help you to understand the performance bounds of the application, how it will scale in the real world, etc. It also helps you to understand how numbers can lie, and the difference between good sampling and bad sampling (this microbenchmarks).
...but then CS isn't about good coding, it's about taking over the world (y'know, "science"). IMHO there is nothing better for good coding than to slow down, do a tiny thing at a time, and wonder what path execution will follow when your assumptions are wrong.
Hear hear!
Developers need to experience a benefit from the practices they are asked to adopt, or they will have no internal motivation to adopt them. In that case you are forced to use external motivators (rewards or punishment) which are never as effective.
There are only two reasons to introduce a practice: (1) to improve productivity; and/or (2) to CYA (cover your ass). Any practice that doesn't do one of those is worthless.
Practices that improve productivity should (and generally do) appeal to developers. Such practices usually involve working smarter rather than harder, isolating developers from mistakes or inconvenience caused by other developers, and taking care to reduce mistakes early in the development cycle (so less frustrating debugging at integration time). Take the time to ensure that developers understand what the practice will do for them, and they'll have an intrinsic motivation to follow it.
Practices that CYA are more difficult to implement. These represent business concern about liability that course arise from the way things are being done. That could involve labour issues (developers have been under pressure to work overtime), intellectual property (someone is copying GPL code into the code base), or following industry norms so that you can't be sued for negligence.
Where industry norms differ from the practices that improve productivity you'll need to educate developers and provide some external motivation (usually punishment) to ensure compliance.
Start by making sure you understand the distinction between Computer Science and its related disciplines, and that this is a CS course. Read the overview report from the ACM Curricula Recommendations..
It is apparent from the ACM's recommendations (amongst others) that a lot of mathematics traditionally covered at universities(such as calculus) is not strongly related to Computer Science. That said, there are many applications of computing that require strong skills in these areas (scientific computing and cryptography for example) so they are not a bad option.
Important numerical and logical fundamentals that support the learning and use of undergraduate Computer Science include:
At the ever-present risk of starting a religious war ;) ... Tcl
GUI hello world app:
GUI hello name app:
Tcl can load its scripts from a file, or execute them interactively, making it a wonderful environment in which to play around.
I believe Python has similar qualities, although I have barely worked with it.
Single Sign-On and Trusted Third Parties don't solve all your problems. As the original poster said, these include database passwords, and will probably include things like passwords for network devices (routers, firewalls, switch management interfaces). These require a password management solution, not SSO or TTP.
There are a couple of enterprise password management products available that can provide ACL controlled access to passwords. They are mostly expensive, and some are inflexible.
A cheaper solution is to use something like Password Safe with a network-accessible database. Identify a limited set of users and share the safe password between them. Then keep that password locked in a dual-access-only safe or vault for disaster recovery.
If you have different classes of users that only need a subset of passwords (network admins, DBAs, account system admins) then use one password safe database per class. Obviously each database will have a unique password ;)
For more complex environments where you need the flexibility of ACLs, you'll have to get an enterprise product.
Yeah, because the moment I do know my (hypothetical) kid is breaking the law, it becomes my legal obligation to (a) report the crime, and (b) take action to prevent my property from being used in the commission of future crimes of this sort. So unless I ground the kid or take appropriate action to "reeducate" him/her/it not to repeat the crime, I share in the criminal liability.
So no, this isn't good for anyone.
Which is why you're not a CEO.
Real humans make mistakes. The best developers may be less likely to make big mistakes and introduce logic bugs, but even they will commit simple errors from time to time. So there is always a need for review, be it human or automaton.
It is not easy to find "the best" developers, or to distinguish them from above average developers (and average isn't very good). It was recently shown that "the best" people in their field consistently rate themselves lower than the set of people who are just below them -- essentially they have reached a level of maturity and knowledge to understand their weaknesses.
It takes a good developer at least a month to become familiar with a new environment (the policies and procedures, "how things are done here", basic navigation of the source tree(s) and tools), for a simple environment. In an environment dominated by domain specific knowledge or industry standards it can take 4 to 6 months to become productive. That's one heck of an investment, and to then decide "this guy ain't good enough" is not justifiable in business terms.
Further, "the best" developers are also the most mobile, and the most expensive. After you've invested in getting them familiar with your environment, they are the most likely to leave.
So instead you consider finding a very small number of "the best" developers, and staffing up on "average" developers. Then you invest in quality assurance, ideally guided by "the best" developers, to ensure that everyone is keeping the standard.
The benefit of tools like this is that they are not responsive to arguments or pressure or transient underperformance. You can always argue with a human reviewer that the code is right and the reviewer is wrong (unless the reviewer has a set of cast-in-stone laws to be checked, which makes the reviewer simply a fallable automaton). Managers can always pressure reviewers to be more lenient because of time pressue. Reviewers can have an "off day" and miss potentially large bugs. These tools don't catch everything -- they aren't a replacement for competent human review -- but they do catch and prevent large groups of trivial, avoidable and easily missed errors.
The audio CD format uses error correcting codes (See Reed-Solomon_error_correction). I don't believe CDR data formats do (but I could be wrong about that). Anyway, it would appear that scratches are more likely to cause tracking errors than non-reflective marks, which makes it easier for the drive to access and error correcting codes and reconstruct the damage.
Witch hunts since the colonisation of North America have mostly been about subjugation of women.
Is she trying to have her own opinions with her husband's permission? Must be a witch. Husband sleeping with a younger, prettier woman? Couldn't be him! She must be a witch. Woman trying to read or get an edumacation? Unnatural I tell you! Must be a witch! Widow without a husband or children being an economic burden on the town? Well she must be a witch -- Godly people have children you know.
I think you have an important point here: national ID numbers can be abused in private hands because they provide a convenient universal identifier for you. So corporations can now share and correlate data about you where, without an ID number, they would have a much harder time matching up the records they all hold to get "complete" knowledge of a particular individual.
In my country (which has national ID) its use is somewhat different. You can't get a bank account, a cell phone, a landline, or just about any arrears-payment service without disclosing your ID number. Nor can you open a credit account with a retail store. And you can't even rent property without providing the landlord with your ID number (unless you deal with really dodgy landlords) because of responsibilities placed on landlords to know their tenants in order to reduce crime. There are no effective data protection laws restricting what can be done with that information by service providers.
I've always had the feeling that national ID should be "your account number with the government". It allows you access to government services, and you have to make payments to the government for that (tax). So in the same way as you wouldn't give your telephone account number to the grocer, your national ID is something between you and the government only.
As soon as you have to disclose your ID number to anyone, it is no longer secret. For example, contracts of transfer for houses are usually lodged in a deeds office, and are subject to public scrutiny. If you do a little bit of looking, you'll find examples that are applicable to your own nation.
All physical documents are easy to fake, in time. This is the reason that most nations replace their paper money and coins ever 8 years or so. But some documents, like drivers licenses and IDs, are meant to last a lot longer ... yet they have weaker security properties than money!
The closest thing we can make right now to an "unfakable" ID document is a smart card with NO information printed on it. The only way to use it is by insertion into a reader which will verify a signature (issued by a trusted registry, probably the government) over a name and image, and then display the name and image.