When it comes to these sorts of things, oft times law enforcement and intelligence agencies who know about a source of major operations DON"T shut them down, so as to build a case against the bigger players or to maintain the ability to track what is going on. Given that this is a US-based corporation with US-based servers, I wonder if this shutdown has seriously compromised on-going monitoring and criminal cases. While this has almost certainly seriously disrupted operations of the various bad guys for now, I would give it only a few days before they're back online based at overseas locations where they're less easily reachable. Except for some script kiddies, the operations are all sophisticated enough to use standard techniques such as multiple hardcoded fallback IPs. DNS redirection, and using fake BGP announcements to hijack IP blocks to get back online.
You Are (obviously) Not A Lawyer. Go talk to one who is licensed in the state in which the employment contract is signed and is familiar with technology employment law. In some states (notably California, but also others) the courts have made it clear that employment non-compete clauses cannot be enforced to any practical degree.
Also, all of the terms of a contract are negotiable. For instance, you state that, "they would take ownership of not just what they paid for, but also my changes leading up to this moment". This does not sound like a reasonable position to me. Does the contract really state that, or is it something that you're misreading, or is it a point on which the contract is unclear? Push back -- if this is your first time, you may be surprised at how much of an offer is just a starting point for negotiations. If a section is not clear, propose your own language that clarifies those points.
The same applies to, "which would bar me from ever working on and publishing results for the original open source project itself, even if done separately, in my free time". None of the negotiations I have been involved in have ever had a non-compete that reached this far. Six months, a year, two years after termination of the contract are typical. Depending on the software and the industry, the term may change but a perpetual non-competition clause will almost certainly be thrown out in court.
Another point to note is that the negotiation process is one indicator of what it will be like to work for this company. If they're hardball, take no prisoners negotiators, there's a pretty good chance that they will treat you the same way once you are an employee. In which case, do you really want to work there?
On technical matters, when a court gets it wrong it is usually not the court's fault
As someone who has submitted testimony as a paid expert witness in court cases, I can tell you that often it IS the court's fault. The education of some of the members of the judiciary on technical matters (and not just computer technical matters) is abysmal. There was a judge who ruled that interest on the damages that our client owed should be handled by just doubling the damages. This was completely unfair to our client since it implied an annual interest rate of something like 25%, at a time when the inflation rate was only 3% and AAA bonds were paying something like 4.5%. We had to go through several days of work, filing a petition for reconsideration, and a hearing to correct what should have taken 5 minutes and a calculator, or 30 seconds and a spreadsheet.
I can well believe that the justices got it dead wrong. Very often the judges do not even know the correct questions to ask of the parties to clarify their misunderstandings. There are normally provisions for judges to appoint special masters who have the technical expertise to advise them, but all too often the judges do not avail themselves of them. See the whole train wreck surrounding the Daubert ruling.
Is there any hope? The point of judicial review is to catch errors, but in this case the appellate layer made its own very bad error. We should always remember that judges are human -- and thus are fallible and have friends. With any luck, a neighbor or buddy of one of the justices will point out the error and say, "Joe, you really, really got it wrong there. You need to take that back and re-do it." And these people actually do listen, as they are human.
Nice try, but this scheme is a bad idea. It opens up a really easy DoS attack. All the attacker has to do is present a bogus certificate or SSH host key to a quorum of the notaries. BAM -- the server is now blocked. In fact, if the attacker can do this over a sustained period, he can masquerade as the actual server.
There's a reason why PKI works the way it does. There's a reason why you should use certificates or key pairs for authentication. The proposed system doesn't really help. Given that you can get a real SSL certificate for $15/year these days, only laziness leads to the use of a self-signed certificate.
I read the darn paper (yeah, yeah, I know, this is Slashdot, I'm not supposed to do that). They have a DoS column in their table in the Security Analysis section but don't discuss DoS in the text at all. Notaries need to be well known and are thus obvious candidates for a DNS-based attack. Next!
If you really care about the FSF, you would shut down this project NOW. IANAL, but I am a former anti-trust economist. It is one thing to conduct a protest (such as a picket line) against the policies or actions of a company; it is another thing entirely to interfere with the business of a company (see "illegal restraint of trade"). A court will come down *hard* on the FSF for sponsoring a DOS action on the Genius Bars. The FSF could be fined, enjoined against actions, or both. In addition, the staff of the FSF and individual participants can be fined or jailed. The money that it will cost to defend the FSF against the lawsuits could be better spent on more useful causes. While Apple's lawyers are not the Nazgul, they are not far off the mark either and Apple has shown itself to be willing and able to use them.
Besides, even if consumers are turned off to Apple, where will they go? WinCE? Symbian? PalmOS? Zune?Are *any* of those better? Get real.
For crying out loud folks, this is a true freetard idea at its worst -- an action against a company that alienates the intended audience, accomplishes nothing, and makes the protesters look like unreasonable, wild-eyed radicals.
I haven't seen much from people who have actually been there on this thread. I was an engineer with Apple for seven years, and I think I can speak to what it's like there. Yes, the pay is less than at comparable companies. The hiring managers gripe about it; I know that we lost many good candidates because we couldn't match the offers they got from other high tech companies.
What offsets this? First, like many high tech companies, we got stock options. When the stock price soared recently, employees hit a jackpot. Second, there are long-term benefits from being an Apple employee. Having Apple on your resume is a definite plus in the industry -- it's something that potential employers definitely give weight to.
Additionally, the environment is incredibly stimulating. You are surrounded by the best of the best, and I found myself working up at a level I wouldn't have thought possible. There's also the feeling of being a part of something that you couldn't do by yourself -- and the company culture recognizes more than just the core engineering teams.
Every single user at Apple is responsible for his or her own basic support, with admin privileges. Not just the developers, not just the hardcore techies, but also the secretaries, salespeople, attorneys, etc. And guess what? It all just works, across a wide variety of hardware and OS upgrades. There are maybe a dozen or so internal help desk people answering the phones. They spend most of their time handling what would be Tier 2 or tougher problems in most environments. (Then again, they must have some of the toughest jobs in the business. Half the time they're taking calls from ordinary folks, the other half they're taking calls from the engineers who wrote the OS or designed the hardware.)
IANAL, but I have been an expert witness in many legal proceedings in Federal courts. As a part of discovery, you *have* to give the other side your raw data and details of your methodology. Otherwise, the judge is almost certain to throw out your testimony, as the other side has no way of discovering the weak spots in your case. I was involved with one case where the judge sanctioned one of the opposing experts and it took us three tries to get a decent set of data and models out of them. This had a very negative effect on the credibility of the other side's expert, which pretty well torpedoed their case. (They won as a matter of law, but damages were negligible.) Mind you, the data and models are generally covered by a protective order to maintain confidentiality, but it's so common that the wording is almost boilerplate. SafeNet and the RIAA don't have a leg to stand on here, and I can't imagine why they're bothering to oppose this unless they're pulling an SCO -- in which case, the judge should slap them down HARD.
Just for historical reference, the Navy experimented with something like this back in the 1950's. According to the writeup from the Smithsonian, the Pogo suffered from a lot of control problems due to propwash buffetting near the ground at takeoff and landing. Back then it took a very skilled test pilot to keep it under control; modern flight control systems like those used to keep semi-unstable airframes (such as the F-16) in controlled flight must make similar VTOL handling a lot easier today.
"Quis custodiet ipsos custodes?" -- "who watches the watchers?" In this context, "who holds the codes for the PALs?"
The US has shared information on how to add PALs to a nuclear weapon to just about anyone who has a declared or undeclared nuclear weapon capability. It's in everyone's best interest that nuclear weapons be kept under solid negative control, to make the "mad general" or "stolen weapon" scenarios a little bit less scary. It does not mean that the US or any other nation holds the PAL codes to Pakistan's nuclear weapons; and I can certainly see why any Pakistani government would object to someone else holding the codes.
The big problem is that there are large segments of the Pakistani military (particularly the Interservice Military Intelligence branch, according to reports) that are sympathetic to the radical Islamic factions and might hand over the PAL codes along with a weapon. Another "what if" is the scenario where a radical Islamic government comes to power that wants to provide a nuclear weapon to al-Qaeda and/or the Taliban as a matter of policy. If this is a legitimate government with support from the military then they will have access to the PAL codes. Under the geopolitical circumstances (particularly the tensions with India over Jammu and Kashmir), I would think that a Pakistani general would want the country's political leadership to be able to authorize release of nuclear weapons as a deterrent to India, regardless of whether or not the general was a supporter of radical Islam.
Even if a general or group of generals managed to lose all of the current PAL codes, a legitimate government would be able to reconsitute the PALs with new codes in a matter of weeks to months. Under that scenario, the government might even decide to reconstitute the weapons without PALs to prevent a like-minded group of generals from cutting them off again. To my mind, this would be an even worse outcome.
Unfortunately, to an outsider such as myself (and likely most of the rest of the world) the internal workings of Pakistan's political and military structure are opaque and Byzantine. I certainly don't claim to understand how all of the various factions and pressures are likely to play out. I can only speak to the obvious and confirmable -- but the actual outcomes are likely to depend most on the parts that I cannot observe or confirm. Along with a U.S. government that seems to base its decisions only on the obvious and substitutes jingoism and ideology for any hint of rational thought, this is a truly worrisome situation.
Another new feature coming in Leopard is Sandboxing (systrace), which limits an application's access to the system by enforcing access policies for system calls
Folks,
Just FYI, the sandboxing in Leopard is not systrace. Systrace is vulnerable to race conditions -- see Robert Watson's paper "Exploiting Concurrency Vulnerabilities in System Call Wrappers". I asked him about this at WWDC, and he told me that Leopard's sandboxing is based on a different technology and is not vulnerable to the same attacks.
Kennedy wasn't right-wing, but he effected the space program as a reaction to the Soviet space successes
Glory Hallelujah! Someone actually knows how to use the word "effected" in a grammatically correct fashion on Slashdot! Congratulations! You, sir or madam, are far too good for this site!:-D
I am a former Apple employee who still maintains close ties to the company. I am also a former professional economist; I went to grad school for my Ph.D., but didn't finish my dissertation. I can state affirmatively without breaking any NDAs that The Fine Article is full of bullsh*t.
Let's start with his sales figures. "The Mac's *worldwide* market share was 3 percent as of June 2007, according to Roger L. Kay, president of Endpoint Technologies Associates, a consulting firm in Wayland, Mass." (Emphasis mine) Worldwide market share is a poor indicator of Apple's markets. It is mostly a US-focused company and will stay that way in the near future. In the US, Apple's market share is around 5-6%, according to the most recent figures I could find. More importantly, the growth rate is more than four times higher than the industry growth rate, 32% vs. 7.2% (IDC estimates via Apple's latest quarterly report). It doesn't take long for that kind of second order effect to dominate. Comparing the market share now (after the events of the 1990's) to Apple's market share when its mainstay was the Apple II is really bad analysis. I would expect better from the author, a professor of business who presumably knows basic microeconomics.
His figures for the share of computers in use are suspect as well. "Funny thing, though: based on the ratio of Windows and Macs actually in use, no gains can be seen for Apple. The Mac's share of personal computers has actually edged a bit lower since Vista's release in January, and the various flavors of Windows a bit higher, according to Net Applications, a firm in Aliso Viejo, Calif., that monitors the operating systems among visitors to 40,000 customer Web sites." Measuring OS usage share by measuring browser hits is a seriously flawed methodology. There are know sources of bias that lead to higher than actual market share figures for Internet Explorer on Windows, including sites that require users of other browsers to spoof the user agent header, measuring usage on sites that have ActiveX elements that drive away non-Windows users, and extra files being sent to Internet Explorer in order to work around problems in the IE rendering engine. Furthermore, the author is looking at the wrong figures and the drop that he's looking at is statistically insignificant anyway. The figures that he refers to are 4.68% (2007Q1) vs. 4.63% (2007Q2). Windows Vista was released to the general public on January 30, 2007. Thus, the base figure he should be using is 4.06% (2006Q4), which predates the release of Vista. A simple statistical test based on the Net Applications market share figures for 2004Q4 through 2007Q2 shows that a 0.05% difference is not statistically significant. Heck, any reasonably trained economist should be able to eyeball this and say that given that trend, a 0.05% difference is not statistically significant.
As far as the whole Best Buy thing goes, the author completely misses the point behind Apple opening its own retail stores. Apple tried for years to work with CompUSA, Sears, Best Buy, and other consumer electronics retailers to sell Apple computers to the masses. Each attempt was a dismal failure, as the personnel at the retailers could not sell something as complex as Apple's equipment. They were barely able to sell TVs. The only sort-of, kind-of successful experiment in there was the store-within-a-store at CompUSA, which was done by putting Apple employees into CompUSA stores. Even that didn't work too well, as the Apple section got lost in the middle of all of the other stuff. Apple is trying again to expand it's retail reach, but I would put the odds against it. Big box retailers' emphasis on low price and minimal service is completely at odds with how to sell Apple computers.
"Apple has not even begun to try to re-enter another domain from which it had withdrawn its Mac sales teams: large corporations." That would be news to Apple's entire Enterprise Sales team -- several hundred people. I work with them on a daily basis, even now. They've been there all alon
TFA does not ask the right question, and McConnell does not answer it:
"Was the surveillance covered by the relatively uncontroversial provisions for surveillance conducted overseas, was it covered by the relatively uncontroversial provisions where the surveillance is reviewed by the appropriate court, or was it done under the provisions for warrantless wiretaps and data mining that are very controversial?"
Are McConnell and the Bush administration trying to run a public relations gambit by association again? Are they trying to use the fact that electronic surveillance of some sort, possibly based on relatively uncontroversial provisions in the Foreign Intelligence Surveillance Act, led to the arrests to get the controversial provisions of the FISA extended as well? I recognize that this may be classified information that should not be publicly disseminated. However, our elected representatives should be asking these questions and have a right to get truthful, complete, and non-evasive answers from the executve branch. If they do receive evasive answers, then the assumption should be that these programs are not necessary and should not be renewed.
Another alternative to a Golden Triangle is to use Centrify for the Mac if you have Windows sysadmins who just won't countenance a Mac server. Centrify uses the same underlying mechanisms as Workgroup Manager but lets a directory admin on a Windows server manage the Macs as though he were applying GPO's to Windows machines. While I think a Golden Triangle is preferable, Centrify works well when you just can't install a Mac OS X Server.
Deliberately crashing the IFE system is no great accomplishment. At least some of the darn things crash themselves just fine with no abuse. I was on a Virgin Atlantic flight from Washington, DC to London a couple of years ago, and the IFE systems would crash on a regular basis by groups of four seats. You could be blissfully watching a movie and then poof, everything goes dark. The flight attendant would reset the system and then sometimes it would come back up and other times it would just sit there at a dark screen. Uptimes varied from 10 minutes to a couple of hours. Very, very frustrating, both for the kids trying to play but getting frustrated and cranky and for the parents trying to keep their sanity during an eight hour flight.
...familiarize the development team with the telephony API (in our case TSAPI, since the client uses an Ericsson PBX) as a simple click 'n dial application...
We need a database is fast so that it can assign the calls without delays.
...but the numbers of requests will increase exponentially once the 'main' parts of the system are implemented...
...(we have about 60000 requests per day currently most of them being cross table queries but finally they should be seven or eight times this number).
Another aspect is the reporting agent, which will operate on the same database and also needs to be fast. Keep in mind that cost matters a lot.
Geez, you aren't asking for much. You have a development team that is inexperienced in the technology, a large anticipated growth factor, complex queries, requirements for high performance on both the incoming call and reporting ends, and low cost. Have you ever heard the phrase, "good, cheap, quick -- pick two"? In this case you have a complex problem domain and high performance requirements, and you want low cost, i.e., "good" and "cheap". Then you're going to have to accept "not quick". I hope you don't expect to deploy this sucker any time soon.
Only requirement is you add a key as soon as you reboot the box or your scripts don't work. A simple ssh-add -l will show keys and you can have the scripts exit/email error if no keys are added to the agent.
And there's the problem -- what if you need unattended rebooting, e.g. a box that undergoes an automated reboot to clear a problem? You won't be there to enter the passphrase for the key.
There's always been a fundamental disconnect between the underlying model (data and their relationships to one another) and the tasks that users need to perform. Nearly always, users need to bring together data from disparate parts of the model to perform their tasks, generally in the same context (e.g on the same web page or in the same window).
I'm a WebObjects hacker, and I've tried to use the Direct-to-Web and Direct-to-Java Client technologies as the basis for an application many times. These read the underlying data model and automatically generate either a web application or a Java Swing application for you, customizable via a set of conditional rules. However, every time that I've done so I have ended up either re-doing the application via a more conventional WebObjects implementation, or the amount of customization has ended up being so great that the level of effort was roughly the same as if I had started from scratch.
Don't believe the snake oil salesmen, and don't let your management believe them either.
I have mod points, but I don't see anyone chiming in here about realistic load testing.
For this kind of application, you must, *must*, MUST create a heavy load on a production system. I've done work with big, complex, multi-threaded web apps that have similar characteristics -- event-driven (when an HTTP request comes in) and server-only (no GUI). There are many bugs that don't show up until you put the system under load, as in dozens or hundreds of transactions per second. For instance, under light load a queue will never fill up, but under heavy load bizzarro, difficult-to-trace bugs will crop up that you can't reproduce on your development system. Even under the same load, your development system may run into a different constraint (e.g. CPU-bound so that it can't fill the queue fast enough and thus never hits the bug).
To have any hope of catching these bugs, you need to instrument your application heavily, with logging calls that you can turn on and off easily with some sort of switch (kill signal, special dialing code, etc.). Running with a debugger attached will likely be next to impossible on your production or staging systems.
Lastly, definitely invest in an automated test environment. You will need to do these kinds of debugging runs hundreds of times in the course of developing your app, and it just isn't feasible to have everyone in the company drop what they're doing and call into your app a dozen times a day. While there are plenty of load test tools for web apps, I'm not familiar with any for telephony apps, although some must exist. You may end up rolling your own from a bunch of old modems.
Good luck, as the bugs in these systems are notoriously difficult to hunt down.
What's really amazing/frightening to me is how long it has taken for the mainstream media to pick this up. The tests done by Harri Hursti for Leon County were conducted and reported back on December 13th, 2005! The Post waited until a slow news day over a month later to report on it. Since then, there's been a whole slew of additional activity on the voting machines front. For more details, see the original blackboxvoting.org article.
--Paul
Disclaimers: I have been working with the good folks at TrueVoteMD.org to get the d*mned things banned in Maryland, my home state; I'm also a plaintiff in a lawsuit in Maryland that seeks to force the Maryland State Board of Elections to follow exsting state law and get rid of them.
Have you considered WebObjects?
on
JSF vs ASP.net
·
· Score: 2, Informative
If you're looking into alternatives, perhaps you should consider Apple's WebObjects. It's essentially what JSF is trying to be, along with a robust, mature, *lightweight* JDBC object-relational mapping and object persistence layer that is scads more mature than Entity EJB's. Pure Java, runs on J2SE 1.3.1+, deployment licenses amount to $499 per server (free with XServes). It's also highly scalable -- this is the technology that drives the Apple Store online, the iTunes Music Store, and Apple's.Mac service.
--Paul (disclaimer -- I work for Apple; however, I've been doing web development using ASP, J2EE, and WebObjects for years. IMHO WebObjects is far more elegant and robust than the alternatives.)
Geez, first thing to do is profile the application, under expected heavy usage patterns. This can be a bunch of looping scripts running wget or the like, or a bunch of testers (never underestimate the cost-effectiveness of a bunch of student volunteers on a weekend day - they likely will work for donuts and juice), or a commercial load test tool.
See how hot and heavy things can get before something chokes. Then you'll know whether your application is compute-bound, memory-bound, disk I/O-bound, or what. Also, whether it's Apache itself or the MySQL database that's getting hung up.
Also, look at your current usage logs. You say that your site, "requires users to log-on to the website for extended period of time" and also that it has "about 1,200 users, 5-7% connected at any given time". Are there usage patterns or spikes that you need to worry about? Is there a morning login activity spike? Is there a lunch spike or a leaving-for-the-evening spike? How high are they relative to the general background and to each other? What about popular pages? Are there three or four pages that could be statically generated on a periodic basis to relieve a big chunk of the load? How much of the site can realistically be cached across all users, vs. across a user, vs. must be generated afresh with each request? During the long logged-on period, are users actively doing things the whole time, or are they doing a "click here, three clicks half an hour later, another click ten minutes after that" kind of sporadic activity pattern?
Once you know where the bottlenecks are and the likely usage patterns, then you can apply the optimizations that other folks have spoken about. I've deployed a number of large-scale WebObjects systems, and one thing I can assure you is that your initial impression of what's important to users and what really is going to cause a load is wrong. Users will find new ways to work and a seemingly innocuous routine may end up being called thousands of times.
--Paul
PS - don't forget code optimization. At least half of the slowdowns that I have found in deploying web apps can be classified as bone-headed programmer issues. E.g. - inserting nodes into a linked list one by one, when I should have known that the inserts would come in groups that needed to go into the same place. I should have (and later did) gather them up and do a single insert instead of repeatedly traversing the linked list.:-P
For example, an administrator can be denied access to a file. The admin can change the ACLs by taking ownership, but doing this generates a log event. Deleting the logs generates another log event. AFAIK, it's impossible to restrict the unix superuser in this way.
You're comparing an administrator user (which is a preset level of privilege on Windows) with the root user on a Un*x system, which is apples to oranges. The root user on Un*x is more properly compared to the LocalSystem account on Windows. The key difference is that the LocalSystem account never has a password so you can never log in as LocalSystem. However, many Un*x systems (e.g. Mac OS X) also have root accounts that don't have a password (and thus you cannot log in as root) or at least disallow remote root logins, giving them similar levels of account protection.
In fact, the restrictions on the default administrator account on Windows are weaker than those given to administrator accounts on Mac OS X -- a Windows admin can write to \Windows\System32 without elevated privileges, which pretty much means game over if the attacker can get the admin to execute a script (e.g. through a browser flaw) that puts DLL's into the directory. In contrast, a a Mac OS X admin needs to authenticate and temporarily gain elevated privileges to write to the equivalent location,/System/Library. Even if an attacker fools a Mac OS X admin into running a script, there is still the need to authenticate which gives the admin a chance to halt the attack.
Yes, I understand that, but on most Unix systems changes made by ifconfig stick around until the next reboot (e.g. adding an additional IP address to an interface, or activating an interface). On Mac OS X, changes made by ifconfig can be overwritten at any time by configd, and generally will be overwritten at the least convenient and most difficult to debug time.
Slashdot Mirror
When it comes to these sorts of things, oft times law enforcement and intelligence agencies who know about a source of major operations DON"T shut them down, so as to build a case against the bigger players or to maintain the ability to track what is going on. Given that this is a US-based corporation with US-based servers, I wonder if this shutdown has seriously compromised on-going monitoring and criminal cases. While this has almost certainly seriously disrupted operations of the various bad guys for now, I would give it only a few days before they're back online based at overseas locations where they're less easily reachable. Except for some script kiddies, the operations are all sophisticated enough to use standard techniques such as multiple hardcoded fallback IPs. DNS redirection, and using fake BGP announcements to hijack IP blocks to get back online.
--Paul
Soulskill,
You Are (obviously) Not A Lawyer. Go talk to one who is licensed in the state in which the employment contract is signed and is familiar with technology employment law. In some states (notably California, but also others) the courts have made it clear that employment non-compete clauses cannot be enforced to any practical degree.
Also, all of the terms of a contract are negotiable. For instance, you state that, "they would take ownership of not just what they paid for, but also my changes leading up to this moment". This does not sound like a reasonable position to me. Does the contract really state that, or is it something that you're misreading, or is it a point on which the contract is unclear? Push back -- if this is your first time, you may be surprised at how much of an offer is just a starting point for negotiations. If a section is not clear, propose your own language that clarifies those points.
The same applies to, "which would bar me from ever working on and publishing results for the original open source project itself, even if done separately, in my free time". None of the negotiations I have been involved in have ever had a non-compete that reached this far. Six months, a year, two years after termination of the contract are typical. Depending on the software and the industry, the term may change but a perpetual non-competition clause will almost certainly be thrown out in court.
Another point to note is that the negotiation process is one indicator of what it will be like to work for this company. If they're hardball, take no prisoners negotiators, there's a pretty good chance that they will treat you the same way once you are an employee. In which case, do you really want to work there?
Just some food for thought.
--Paul
As someone who has submitted testimony as a paid expert witness in court cases, I can tell you that often it IS the court's fault. The education of some of the members of the judiciary on technical matters (and not just computer technical matters) is abysmal. There was a judge who ruled that interest on the damages that our client owed should be handled by just doubling the damages. This was completely unfair to our client since it implied an annual interest rate of something like 25%, at a time when the inflation rate was only 3% and AAA bonds were paying something like 4.5%. We had to go through several days of work, filing a petition for reconsideration, and a hearing to correct what should have taken 5 minutes and a calculator, or 30 seconds and a spreadsheet.
I can well believe that the justices got it dead wrong. Very often the judges do not even know the correct questions to ask of the parties to clarify their misunderstandings. There are normally provisions for judges to appoint special masters who have the technical expertise to advise them, but all too often the judges do not avail themselves of them. See the whole train wreck surrounding the Daubert ruling.
Is there any hope? The point of judicial review is to catch errors, but in this case the appellate layer made its own very bad error. We should always remember that judges are human -- and thus are fallible and have friends. With any luck, a neighbor or buddy of one of the justices will point out the error and say, "Joe, you really, really got it wrong there. You need to take that back and re-do it." And these people actually do listen, as they are human.
--Paul
Folks,
Nice try, but this scheme is a bad idea. It opens up a really easy DoS attack. All the attacker has to do is present a bogus certificate or SSH host key to a quorum of the notaries. BAM -- the server is now blocked. In fact, if the attacker can do this over a sustained period, he can masquerade as the actual server.
There's a reason why PKI works the way it does. There's a reason why you should use certificates or key pairs for authentication. The proposed system doesn't really help. Given that you can get a real SSL certificate for $15/year these days, only laziness leads to the use of a self-signed certificate.
I read the darn paper (yeah, yeah, I know, this is Slashdot, I'm not supposed to do that). They have a DoS column in their table in the Security Analysis section but don't discuss DoS in the text at all. Notaries need to be well known and are thus obvious candidates for a DNS-based attack. Next!
--Paul
Folks,
If you really care about the FSF, you would shut down this project NOW. IANAL, but I am a former anti-trust economist. It is one thing to conduct a protest (such as a picket line) against the policies or actions of a company; it is another thing entirely to interfere with the business of a company (see "illegal restraint of trade"). A court will come down *hard* on the FSF for sponsoring a DOS action on the Genius Bars. The FSF could be fined, enjoined against actions, or both. In addition, the staff of the FSF and individual participants can be fined or jailed. The money that it will cost to defend the FSF against the lawsuits could be better spent on more useful causes. While Apple's lawyers are not the Nazgul, they are not far off the mark either and Apple has shown itself to be willing and able to use them.
Besides, even if consumers are turned off to Apple, where will they go? WinCE? Symbian? PalmOS? Zune?Are *any* of those better? Get real.
For crying out loud folks, this is a true freetard idea at its worst -- an action against a company that alienates the intended audience, accomplishes nothing, and makes the protesters look like unreasonable, wild-eyed radicals.
--Paul
I haven't seen much from people who have actually been there on this thread. I was an engineer with Apple for seven years, and I think I can speak to what it's like there. Yes, the pay is less than at comparable companies. The hiring managers gripe about it; I know that we lost many good candidates because we couldn't match the offers they got from other high tech companies.
What offsets this? First, like many high tech companies, we got stock options. When the stock price soared recently, employees hit a jackpot. Second, there are long-term benefits from being an Apple employee. Having Apple on your resume is a definite plus in the industry -- it's something that potential employers definitely give weight to.
Additionally, the environment is incredibly stimulating. You are surrounded by the best of the best, and I found myself working up at a level I wouldn't have thought possible. There's also the feeling of being a part of something that you couldn't do by yourself -- and the company culture recognizes more than just the core engineering teams.
--Paul
Every single user at Apple is responsible for his or her own basic support, with admin privileges. Not just the developers, not just the hardcore techies, but also the secretaries, salespeople, attorneys, etc. And guess what? It all just works, across a wide variety of hardware and OS upgrades. There are maybe a dozen or so internal help desk people answering the phones. They spend most of their time handling what would be Tier 2 or tougher problems in most environments. (Then again, they must have some of the toughest jobs in the business. Half the time they're taking calls from ordinary folks, the other half they're taking calls from the engineers who wrote the OS or designed the hardware.)
--Paul
Folks,
IANAL, but I have been an expert witness in many legal proceedings in Federal courts. As a part of discovery, you *have* to give the other side your raw data and details of your methodology. Otherwise, the judge is almost certain to throw out your testimony, as the other side has no way of discovering the weak spots in your case. I was involved with one case where the judge sanctioned one of the opposing experts and it took us three tries to get a decent set of data and models out of them. This had a very negative effect on the credibility of the other side's expert, which pretty well torpedoed their case. (They won as a matter of law, but damages were negligible.) Mind you, the data and models are generally covered by a protective order to maintain confidentiality, but it's so common that the wording is almost boilerplate. SafeNet and the RIAA don't have a leg to stand on here, and I can't imagine why they're bothering to oppose this unless they're pulling an SCO -- in which case, the judge should slap them down HARD.
--Paul
Just for historical reference, the Navy experimented with something like this back in the 1950's. According to the writeup from the Smithsonian, the Pogo suffered from a lot of control problems due to propwash buffetting near the ground at takeoff and landing. Back then it took a very skilled test pilot to keep it under control; modern flight control systems like those used to keep semi-unstable airframes (such as the F-16) in controlled flight must make similar VTOL handling a lot easier today.
http://www.nasm.si.edu/research/aero/aircraft/convair_pogo.htm
--Paul
"Quis custodiet ipsos custodes?" -- "who watches the watchers?" In this context, "who holds the codes for the PALs?"
The US has shared information on how to add PALs to a nuclear weapon to just about anyone who has a declared or undeclared nuclear weapon capability. It's in everyone's best interest that nuclear weapons be kept under solid negative control, to make the "mad general" or "stolen weapon" scenarios a little bit less scary. It does not mean that the US or any other nation holds the PAL codes to Pakistan's nuclear weapons; and I can certainly see why any Pakistani government would object to someone else holding the codes.
The big problem is that there are large segments of the Pakistani military (particularly the Interservice Military Intelligence branch, according to reports) that are sympathetic to the radical Islamic factions and might hand over the PAL codes along with a weapon. Another "what if" is the scenario where a radical Islamic government comes to power that wants to provide a nuclear weapon to al-Qaeda and/or the Taliban as a matter of policy. If this is a legitimate government with support from the military then they will have access to the PAL codes. Under the geopolitical circumstances (particularly the tensions with India over Jammu and Kashmir), I would think that a Pakistani general would want the country's political leadership to be able to authorize release of nuclear weapons as a deterrent to India, regardless of whether or not the general was a supporter of radical Islam.
Even if a general or group of generals managed to lose all of the current PAL codes, a legitimate government would be able to reconsitute the PALs with new codes in a matter of weeks to months. Under that scenario, the government might even decide to reconstitute the weapons without PALs to prevent a like-minded group of generals from cutting them off again. To my mind, this would be an even worse outcome.
Unfortunately, to an outsider such as myself (and likely most of the rest of the world) the internal workings of Pakistan's political and military structure are opaque and Byzantine. I certainly don't claim to understand how all of the various factions and pressures are likely to play out. I can only speak to the obvious and confirmable -- but the actual outcomes are likely to depend most on the parts that I cannot observe or confirm. Along with a U.S. government that seems to base its decisions only on the obvious and substitutes jingoism and ideology for any hint of rational thought, this is a truly worrisome situation.
I wouldn't breathe too deeply just yet.
--Paul
Another new feature coming in Leopard is Sandboxing (systrace), which limits an application's access to the system by enforcing access policies for system calls
Folks,
Just FYI, the sandboxing in Leopard is not systrace. Systrace is vulnerable to race conditions -- see Robert Watson's paper "Exploiting Concurrency Vulnerabilities in System Call Wrappers". I asked him about this at WWDC, and he told me that Leopard's sandboxing is based on a different technology and is not vulnerable to the same attacks.
--Paul
Glory Hallelujah! Someone actually knows how to use the word "effected" in a grammatically correct fashion on Slashdot! Congratulations! You, sir or madam, are far too good for this site! :-D
--Paul
I am a former Apple employee who still maintains close ties to the company. I am also a former professional economist; I went to grad school for my Ph.D., but didn't finish my dissertation. I can state affirmatively without breaking any NDAs that The Fine Article is full of bullsh*t.
Let's start with his sales figures. "The Mac's *worldwide* market share was 3 percent as of June 2007, according to Roger L. Kay, president of Endpoint Technologies Associates, a consulting firm in Wayland, Mass." (Emphasis mine) Worldwide market share is a poor indicator of Apple's markets. It is mostly a US-focused company and will stay that way in the near future. In the US, Apple's market share is around 5-6%, according to the most recent figures I could find. More importantly, the growth rate is more than four times higher than the industry growth rate, 32% vs. 7.2% (IDC estimates via Apple's latest quarterly report). It doesn't take long for that kind of second order effect to dominate. Comparing the market share now (after the events of the 1990's) to Apple's market share when its mainstay was the Apple II is really bad analysis. I would expect better from the author, a professor of business who presumably knows basic microeconomics.
His figures for the share of computers in use are suspect as well. "Funny thing, though: based on the ratio of Windows and Macs actually in use, no gains can be seen for Apple. The Mac's share of personal computers has actually edged a bit lower since Vista's release in January, and the various flavors of Windows a bit higher, according to Net Applications, a firm in Aliso Viejo, Calif., that monitors the operating systems among visitors to 40,000 customer Web sites." Measuring OS usage share by measuring browser hits is a seriously flawed methodology. There are know sources of bias that lead to higher than actual market share figures for Internet Explorer on Windows, including sites that require users of other browsers to spoof the user agent header, measuring usage on sites that have ActiveX elements that drive away non-Windows users, and extra files being sent to Internet Explorer in order to work around problems in the IE rendering engine. Furthermore, the author is looking at the wrong figures and the drop that he's looking at is statistically insignificant anyway. The figures that he refers to are 4.68% (2007Q1) vs. 4.63% (2007Q2). Windows Vista was released to the general public on January 30, 2007. Thus, the base figure he should be using is 4.06% (2006Q4), which predates the release of Vista. A simple statistical test based on the Net Applications market share figures for 2004Q4 through 2007Q2 shows that a 0.05% difference is not statistically significant. Heck, any reasonably trained economist should be able to eyeball this and say that given that trend, a 0.05% difference is not statistically significant.
As far as the whole Best Buy thing goes, the author completely misses the point behind Apple opening its own retail stores. Apple tried for years to work with CompUSA, Sears, Best Buy, and other consumer electronics retailers to sell Apple computers to the masses. Each attempt was a dismal failure, as the personnel at the retailers could not sell something as complex as Apple's equipment. They were barely able to sell TVs. The only sort-of, kind-of successful experiment in there was the store-within-a-store at CompUSA, which was done by putting Apple employees into CompUSA stores. Even that didn't work too well, as the Apple section got lost in the middle of all of the other stuff. Apple is trying again to expand it's retail reach, but I would put the odds against it. Big box retailers' emphasis on low price and minimal service is completely at odds with how to sell Apple computers.
"Apple has not even begun to try to re-enter another domain from which it had withdrawn its Mac sales teams: large corporations." That would be news to Apple's entire Enterprise Sales team -- several hundred people. I work with them on a daily basis, even now. They've been there all alon
TFA does not ask the right question, and McConnell does not answer it:
"Was the surveillance covered by the relatively uncontroversial provisions for surveillance conducted overseas, was it covered by the relatively uncontroversial provisions where the surveillance is reviewed by the appropriate court, or was it done under the provisions for warrantless wiretaps and data mining that are very controversial?"
Are McConnell and the Bush administration trying to run a public relations gambit by association again? Are they trying to use the fact that electronic surveillance of some sort, possibly based on relatively uncontroversial provisions in the Foreign Intelligence Surveillance Act, led to the arrests to get the controversial provisions of the FISA extended as well? I recognize that this may be classified information that should not be publicly disseminated. However, our elected representatives should be asking these questions and have a right to get truthful, complete, and non-evasive answers from the executve branch. If they do receive evasive answers, then the assumption should be that these programs are not necessary and should not be renewed.
--Paul
Another alternative to a Golden Triangle is to use Centrify for the Mac if you have Windows sysadmins who just won't countenance a Mac server. Centrify uses the same underlying mechanisms as Workgroup Manager but lets a directory admin on a Windows server manage the Macs as though he were applying GPO's to Windows machines. While I think a Golden Triangle is preferable, Centrify works well when you just can't install a Mac OS X Server.
--Paul
Deliberately crashing the IFE system is no great accomplishment. At least some of the darn things crash themselves just fine with no abuse. I was on a Virgin Atlantic flight from Washington, DC to London a couple of years ago, and the IFE systems would crash on a regular basis by groups of four seats. You could be blissfully watching a movie and then poof, everything goes dark. The flight attendant would reset the system and then sometimes it would come back up and other times it would just sit there at a dark screen. Uptimes varied from 10 minutes to a couple of hours. Very, very frustrating, both for the kids trying to play but getting frustrated and cranky and for the parents trying to keep their sanity during an eight hour flight.
--Paul
Geez, you aren't asking for much. You have a development team that is inexperienced in the technology, a large anticipated growth factor, complex queries, requirements for high performance on both the incoming call and reporting ends, and low cost. Have you ever heard the phrase, "good, cheap, quick -- pick two"? In this case you have a complex problem domain and high performance requirements, and you want low cost, i.e., "good" and "cheap". Then you're going to have to accept "not quick". I hope you don't expect to deploy this sucker any time soon.
--Paul
Only requirement is you add a key as soon as you reboot the box or your scripts don't work. A simple ssh-add -l will show keys and you can have the scripts exit/email error if no keys are added to the agent.
And there's the problem -- what if you need unattended rebooting, e.g. a box that undergoes an automated reboot to clear a problem? You won't be there to enter the passphrase for the key.
--Paul
There's always been a fundamental disconnect between the underlying model (data and their relationships to one another) and the tasks that users need to perform. Nearly always, users need to bring together data from disparate parts of the model to perform their tasks, generally in the same context (e.g on the same web page or in the same window).
I'm a WebObjects hacker, and I've tried to use the Direct-to-Web and Direct-to-Java Client technologies as the basis for an application many times. These read the underlying data model and automatically generate either a web application or a Java Swing application for you, customizable via a set of conditional rules. However, every time that I've done so I have ended up either re-doing the application via a more conventional WebObjects implementation, or the amount of customization has ended up being so great that the level of effort was roughly the same as if I had started from scratch.
Don't believe the snake oil salesmen, and don't let your management believe them either.
--Paul
I have mod points, but I don't see anyone chiming in here about realistic load testing.
For this kind of application, you must, *must*, MUST create a heavy load on a production system. I've done work with big, complex, multi-threaded web apps that have similar characteristics -- event-driven (when an HTTP request comes in) and server-only (no GUI). There are many bugs that don't show up until you put the system under load, as in dozens or hundreds of transactions per second. For instance, under light load a queue will never fill up, but under heavy load bizzarro, difficult-to-trace bugs will crop up that you can't reproduce on your development system. Even under the same load, your development system may run into a different constraint (e.g. CPU-bound so that it can't fill the queue fast enough and thus never hits the bug).
To have any hope of catching these bugs, you need to instrument your application heavily, with logging calls that you can turn on and off easily with some sort of switch (kill signal, special dialing code, etc.). Running with a debugger attached will likely be next to impossible on your production or staging systems.
Lastly, definitely invest in an automated test environment. You will need to do these kinds of debugging runs hundreds of times in the course of developing your app, and it just isn't feasible to have everyone in the company drop what they're doing and call into your app a dozen times a day. While there are plenty of load test tools for web apps, I'm not familiar with any for telephony apps, although some must exist. You may end up rolling your own from a bunch of old modems.
Good luck, as the bugs in these systems are notoriously difficult to hunt down.
--Paul
What's really amazing/frightening to me is how long it has taken for the mainstream media to pick this up. The tests done by Harri Hursti for Leon County were conducted and reported back on December 13th, 2005! The Post waited until a slow news day over a month later to report on it. Since then, there's been a whole slew of additional activity on the voting machines front. For more details, see the original blackboxvoting.org article.
--Paul
Disclaimers: I have been working with the good folks at TrueVoteMD.org to get the d*mned things banned in Maryland, my home state; I'm also a plaintiff in a lawsuit in Maryland that seeks to force the Maryland State Board of Elections to follow exsting state law and get rid of them.
If you're looking into alternatives, perhaps you should consider Apple's WebObjects. It's essentially what JSF is trying to be, along with a robust, mature, *lightweight* JDBC object-relational mapping and object persistence layer that is scads more mature than Entity EJB's. Pure Java, runs on J2SE 1.3.1+, deployment licenses amount to $499 per server (free with XServes). It's also highly scalable -- this is the technology that drives the Apple Store online, the iTunes Music Store, and Apple's .Mac service.
--Paul
(disclaimer -- I work for Apple; however, I've been doing web development using ASP, J2EE, and WebObjects for years. IMHO WebObjects is far more elegant and robust than the alternatives.)
Geez, first thing to do is profile the application, under expected heavy usage patterns. This can be a bunch of looping scripts running wget or the like, or a bunch of testers (never underestimate the cost-effectiveness of a bunch of student volunteers on a weekend day - they likely will work for donuts and juice), or a commercial load test tool.
:-P
See how hot and heavy things can get before something chokes. Then you'll know whether your application is compute-bound, memory-bound, disk I/O-bound, or what. Also, whether it's Apache itself or the MySQL database that's getting hung up.
Also, look at your current usage logs. You say that your site, "requires users to log-on to the website for extended period of time" and also that it has "about 1,200 users, 5-7% connected at any given time". Are there usage patterns or spikes that you need to worry about? Is there a morning login activity spike? Is there a lunch spike or a leaving-for-the-evening spike? How high are they relative to the general background and to each other? What about popular pages? Are there three or four pages that could be statically generated on a periodic basis to relieve a big chunk of the load? How much of the site can realistically be cached across all users, vs. across a user, vs. must be generated afresh with each request? During the long logged-on period, are users actively doing things the whole time, or are they doing a "click here, three clicks half an hour later, another click ten minutes after that" kind of sporadic activity pattern?
Once you know where the bottlenecks are and the likely usage patterns, then you can apply the optimizations that other folks have spoken about. I've deployed a number of large-scale WebObjects systems, and one thing I can assure you is that your initial impression of what's important to users and what really is going to cause a load is wrong. Users will find new ways to work and a seemingly innocuous routine may end up being called thousands of times.
--Paul
PS - don't forget code optimization. At least half of the slowdowns that I have found in deploying web apps can be classified as bone-headed programmer issues. E.g. - inserting nodes into a linked list one by one, when I should have known that the inserts would come in groups that needed to go into the same place. I should have (and later did) gather them up and do a single insert instead of repeatedly traversing the linked list.
For example, an administrator can be denied access to a file. The admin can change the ACLs by taking ownership, but doing this generates a log event. Deleting the logs generates another log event. AFAIK, it's impossible to restrict the unix superuser in this way.
/System/Library. Even if an attacker fools a Mac OS X admin into running a script, there is still the need to authenticate which gives the admin a chance to halt the attack.
You're comparing an administrator user (which is a preset level of privilege on Windows) with the root user on a Un*x system, which is apples to oranges. The root user on Un*x is more properly compared to the LocalSystem account on Windows. The key difference is that the LocalSystem account never has a password so you can never log in as LocalSystem. However, many Un*x systems (e.g. Mac OS X) also have root accounts that don't have a password (and thus you cannot log in as root) or at least disallow remote root logins, giving them similar levels of account protection.
In fact, the restrictions on the default administrator account on Windows are weaker than those given to administrator accounts on Mac OS X -- a Windows admin can write to \Windows\System32 without elevated privileges, which pretty much means game over if the attacker can get the admin to execute a script (e.g. through a browser flaw) that puts DLL's into the directory. In contrast, a a Mac OS X admin needs to authenticate and temporarily gain elevated privileges to write to the equivalent location,
--Paul
Yes, I understand that, but on most Unix systems changes made by ifconfig stick around until the next reboot (e.g. adding an additional IP address to an interface, or activating an interface). On Mac OS X, changes made by ifconfig can be overwritten at any time by configd, and generally will be overwritten at the least convenient and most difficult to debug time.
--Paul