An expert's opinion ought to be worth more than a layman's. If someone goes to congress, in an expert capacity, to discuss an issue, they are not doing so on the grounds of being your average punter - they are doing so under the auspices of fundamental expertise on the issue being raised.
That is not the same as your mom calling your Senator on the same issue. There's democracy and there's tyrrany of the majority; expertise needs to matter. The whole point of policymakers is that they're *not* the people who are experts on an issue; simply people whose job it is to find the experts on those issues and navigate a policy.
Strikes me as a lot closer to the civil war. A lot of good developers, our brothers and sisters in the South and North, are going to get hurt in the process of fighting a war that neither side can actually "win" - resulting in one side that claims victory, but changes none of the behaviour that led to that war's existence in the first place.
The civil war did not end slavery; Microsoft's licensing war will not end intellectual property practices.
WebKit is now pretty different than KHTML. Adding in platform-specific support is now much easier. cia.webkit.org points at cia.vc's entries for WebKit, where you'll find checkins active on GTK and a re-port in progress to take WebKit back to Qt. There's also some Wx work going on.
I suspect, shortly, we'll be seeing a mass import of code for Win32, and sometime after iphone release, for it.
Ok, let's change the rules a bit. There are lots of very good games that you can probably scrape by on, even with some arthritis. You'll always be able to enjoy Half-Life 2, probably, as well as most other FPSes.
Let's try this: There are several reeeeeeally good games out there that, even without arthritis, left my hands sore and painful. Blame the controllers, if you like - but play them now, when the pain won't be excruciating, rather than later.
Metroid Prime and Metroid Prime 2 both qualify; keeping the buttons depressed during very long periods of time for targeting left the fingers of my left hand feeling like I had bent them the wrong way around. They're great games, both gamecube games, and you should play them both. If you're worried about difficulty, grab an Action Replay and cheat your way through it, so you get the whole experience.
I'm struggling to think of others offhand - but they definitely exist. There are some great games out there that, due to controller layout and gameplay behaviour, leave you in pain after long gaming sessions. Play them now and get them out of the way, and never look back.
Then pick up a Wii and say goodbye to thumbsticks. There's always keyboard/mouse on the PC as well.
And good luck; I'll make sure to request that the question be reposted in 10 years time, when I'll be where you are.:)
Ultimately, the problem with variety isn't player confusion - though that surely is a very real problem for players.
The problem with offering variety is the need to ensure that variety doesn't lead to unbalanced play. Someone else hit it on the nose - huge amounts of variety leads to huge amounts of testing. It doesn't matter whether or not some builds work well and others don't - while ideally you want to avoid that kind of situation, it's not actually going to damage the game itself, just the players' experience.
The problem is with unbalanced characters created for the purposes of farming the world. Game developers have to work hard to balance and carefully tune the rate at which resources can be plundered from the world, or the whole economy goes up in smoke. For those who have been in a game where the economy has done just that, they can attest how hard it is to play a game where the economy is buggered.
Ultimately, it's all about the virtual Benjamins. The further a game gets from needing to maintain an economy and control the rate of loot acquisition, the more flexibility it has to experiment with variety.
It's a valid point, even if we're not listening properly. WiFi is pretty much de-facto now - you can expect most people to want WiFi.
And yet, the support for it is *crap*. Unlike almost everything else, where the open source community have come up with good solutions (and in some cases, in partnership with manufacturers) to these problems, Linux WiFi sucks.
Buy a graphics card tomorrow; it probably works. People who know little will be able to use it. Buy a sound card tomorrow; it probably works. Ditto.
And go all the way down the parts list, including physical network cards, and you'll have the same response. Go within ten feet of WiFi, and you're gambling - there's a 50/50 chance it works. And if it does work, it may require you to do something rather unusual - to use Windows drivers, because there aren't any for Linux.
Honestly? ndiswrapper is the worst thing to happen to Linux OSS in a long time - it's meant that people can wave their hands and call it "solved", without actually solving it for most of the population of non-technical users.
It's a shame, really, that we're at this crossroads so late - yet, here we are, and it's fourth and inches from ndiswrapper being EOL. With no general solution for how to improve WiFi for the majority of users once it goes.
Let's face it folks: Something needs doing, and the OP has a point, even if he didn't know he was making it.
They're being slashdotted. Not directly, of course, as nobody can just click to log in - but *everybody* is running over to the server and creating toons on it in order to go and see the new content. People had been warned that it was happening, everyone knew that this was going to end up being the fate of the first server to open the gates.
What can you do when 5+ million players all want to see the new content, but their own server's gates aren't open?
It just doesn't cope. It's fine if you've got no data to speak of; it's great when the sizes of what it's working with is small.
IT TAKES 24 HOURS OF UNWRITABILITY TO MAKE A DAMN BACKUP, FOLKS.
MySQL was the biggest mistake I ever made. I had the option of choosing Postgres on an older version of the software, or MySQL on the latest, and I've been regretting it ever since.
The fact is this: I've used it for stuff when the amounts of data are small, and it's brilliant - but if you need to keep a lot of information, you're screwed - run, don't walk, to the nearest vendor and get something decent, because MySQL just can't cut it. It's missing too much in too many places.
Now, I haven't used 5. I'll have to, because 4 sucks, and 5 can't be worse - I can only hope that 5 gets rid of the worst of my problems; it will probably stay slow and unresponsive, and continue to take an hour to generate a report, but I can at least pray that perhaps, if I'm lucky, I can get a backup out of it without taking down the system.
No matter how good you think it is; no matter how fast you think it might be... don't pretend it scales up to the kinds of loads the commercial vendors can handle. There's a reason the big boys cost big money, and despite popular opinion, it's not all just leeching money out of your pocket. MySQL doesn't do big well.
TCP_ would be the reason that the TCP related portions of his tests - you know, "apache", and "mysql", and stuff - sucked.
As for the "microkernel"... You do know it's not Mach in microkernel mode, right? It doesn't mean it doesn't have its problems, but it does mean that Mac OS X doesn't have a microkernel.
OK, no, that's my point - you're missing the point.
If the point of the article is "why mac os x is a poor server install", going around talking about a bunch of untuned applications is a poor way to do it.
Most of us who do high-performance servers aren't interested in whether bog-standard package installs do well, because we don't expect any platform's bog-standard install to be good enough.
Every kernel needs to be tuned for performance. Every kernel, therefore, needs to be tunable. Talking about where Mac OS X *isn't* tunable, therefore, makes for a good way of talking about where the flaws are.
Knowing that it's got major problems with its TCP implementation is another good way of knowing what the true problems will be; knowing about the high cost of context switches, and syscalls, on the platform...
And going into it, that's what I'd expect an article to talk about. Talk about the *real flaws of the OS*.
Running Apachebench? What does that tell me about the OS? All it tells me is that some idiot thinks that an RPM install of Apache is good enough to handle high volume content delivery - and alone, on an off-the-cd install of Redhat, it's not. Or any other platform. If someone else's support-tuned, 'good enough to ensure the vendor doesn't get calls about stability' is good enough to equate to a high-performance environment where high performance is actually *required*, then we're not talking about the same things - and you might as well buy anything.
People who actually need to run high performance systems don't expect good performance out of package installs. They're untuned. You *expect* to build it (for example) for a G5-only optimized system, tuned for your hardware, on the latest compiler you can get your hands on and verify stability of. Not run it on whatever was built to make some support bod's job easy.
So for people intending to *actually make a decision about the OS as a server platform*, this article is actually a sham.
Having said that, I think that Darwin is a pretty crappy kernel for high performance applications. So, as the subject says, there are problems, but these aren't them.
Fix the latency problems across the user/kernel boundary. Reduce dramatically, please, the cost of context switching that makes heavily threaded applications crawl. Do something about the bugs in the TCP implementation, which prevent most applications expecting Linux-like behavior out of the socket system to *not suck* when run on Darwin.
But don't cry about how the package installs aren't good enough - because they're not 'good enough' on anybody's platform when it comes to a high performance delivery system. If they were, people wouldn't run Gentoo.
If that's what you're expecting, then you're going to be disappointed to find out that every OS vendor ships bugs in their server operating systems, and that every application developer ends up having to do work to make sure that their applications avoid those bugs.
All of us.
So this whole "OS X sucks as a server" thing can be justified on a lot of grounds, but NOT THIS ONE. Cry more about how bog standard vendor installs aren't high performance monsters. Cry more about how application developers shouldn't have to work around bugs in vendor operating systems.
Then go back to Basic on your Colecovision, because that's probably the only OS I can think of that didn't ship with one.
Apple's not special, and just like every other vendor, they ship bugs. And just like every other vendor, they build, test, and ship the applications that come out in a pretty identical way you get to when you./configure && make install.
So, here's the question: Are we talking about the operating system, or someone's ability to run./configure? Are we talking about "Apache being slow", or "the bog standard install being slow"?
Because, for a moment, I thought the whole point of the article was to point out the huge, gaping flaws in the kernel - and someone with the right nail (let's point out the flaws in a kernel) ended up with the wrong hammer (let's run a bunch of applications that don't behave well in standard installs or are old enough to be missing important dev fixes.)
Nowhere did I strain to stick my nose up apple's arse - yet your reaction says it all. You're not actually interested in the point of the article, either, and neither was the author.
You're just looking for a way to stick it to Apple for being crap.
Congratulations, you're a winner - Apple's just another OS vendor, shipping just another set of unusual bugs around, just like the FreeBSD it's built on. It's got a 'colourful' TCP implementation, just like FreeBSD, it's got bugs, just like FreeBSD, and it's got its problems with overhead on PPC, just like FreeBSD.
And Linux 2.4, which also had that TCP bug for a while. And 2.6, which now has a different one. Because, quite frankly, if we all wanted the perfect OS for performance, we'd all be running Solaris, wouldn't we. They don't *ever* get bugs in their kernel.
What a stunningly dumb article. Great high-level point of view on what problems can bubble up and look like, but no low-level understanding of what the problems *are* at all.
For example:
- Under 10.4, you need to ensure sockets get TCP_NODELAY, and that you don't try and use corking via TCP_NOPUSH or TCP_CORK. Memcached users are watching stuff *crawl* when they hit it, depending on the buffer size you happen to be using.
- Whinging about thread creation overhead ignores the fact that just about everything that uses heavily threaded environments use a thread pool and/or worker system - so thread creation overhead is pretty much a red herring in most app design. Sure, it's not brilliant that it's there, but it's also pretty pointless to talk about.
- As anyone who used poll() under heavy load knows, Panther could core dump; Tiger has improved, but it's poll() implementation is still suffering.
- There is, actually, a hidden cost on Macs - POWER state load/store is a lot more expensive, and the context switches are much higher. Tasks which cross the kernel barrier heavily do indeed pay a higher cost on the mac. This requires that folks who are used to 'cheaper' system calls think a bit more about how they can efficiently move their data in the smallest number of syscalls.
- And let's not forget to mention the exponentially more expensive cost of misaligned data access on PPC, easily invoked accidentally in code.
I mean, even once you get past the worse-than-one-might-want performance of the poll() causing problems, you've got the critical problem with TCP latency stepping in.
Strangely enough, all the tests they did that actually show problems are either known bugs, with known workarounds, or are known differences in behavior...
At some point, someone needs to call a spade a spade - was Apache built using TCP_CORK? You betcha. Was he using a fixed version of MySQL? Nope. Did the form of the tests for MySQL also succumb to the TCP_CORK problem? Almost guaranteed.
A poor test. Next time, pay some monkey to *write some code* if you're trying to prove the 'cost of latency'; if you're trying to prove that most Unix software isn't brilliantly optimized to work around issues which have existed on the mac for some time? Well, everything takes time, doesn't it.
On the patentability: Yes, there's oodles of parallel prior art.
On the game itself:
Mustn't be missed. The sanity system is *effective*; it really honestly does warp the player's perspective, make it honestly difficult to know what's real and what isn't, and does actually inspire a creepy sense of dread.
It makes you go out of your way to not create the situations that end up with you being insane. Loss of sanity happens through a few different ways, but basically it's "do something nuts, and go nuts; get hit by something freakish, and go nuts".
If a creature gets the jump on you, your sanity drops. If you get the first shot in, you keep your sanity unless it hits you physically - and then your sanity drops. Physical damage gets fixed, but the psychological damage can only be fixed through a different mechanism.
It's absolutely brilliant, and makes for *riveting* gameplay. Patents like this, which make it harder for people to innovate gameplay, shouldn't be allowed, IMO, if they're overly broad. It's too good an idea to only end up in one game from one company on one system - something like this belongs all over the place.
It's just brilliant.
Just thought I'd pipe in...
on
Lucene in Action
·
· Score: 2, Informative
We moved most of our searching out of SQL and into Lucene for a variety of reasons; and this book has been useful, not just in figuring out good ways of writing those queries that maintain microsecond response times (which Lucene is absolutely brilliant at), but...
- Good ways of doing batch indexing operations
- The purpose of the compound document format
- How to generate explainers for searches
- Field-specific handling, and how to do it well
- Ideas like metaphone replacement (soundex) and use of WordNet to integrate a synonym database into search queries
- When to use CachedFilters to remember complex filters
- Ideas for how to build "Things Like This" lists
- Ideas on autocategorisation and geographic searches
- Named Entities and LingPipe - making the search system recognize "proper names" for things
- NGRAM recording to gauge word frequency and search terms to detect misspellings and offer alternate searches ("Did you mean XXX"?)
etc.
If you're building a search engine, this isn't just a useful resource on implementation - you probably don't need a book for that. What it is brilliant at is providing a lot of ideas that can take you to the next stage - how to build something really cool with your information, and not just a dumb text field search.
For that alone, the book was worth the purchase price, for me. It's now well annotated, and the back pages are full of references to ideas that can be used in our own implementation, and the page numbers to use to get there.
Highly recommended for anyone who needs something more than what a Google search of your site provides.
I mean, let's be frank. There are a *horde* of basic bugfixes that are meant to be in IE7; things which will bring it into compliancy and free an awful lot of people using an awful lot of broken implmentations.
This was supposed to be a real gift and boon to the Web - something Microsoft was finally going to do right. They were going to release a version of IE which fixed most of the glaring bugs, fixed PNG transparency, brought forward a lot of basic technology that all of the other standards-based browsers have.
And now? Now they're not releasing it for the majority of platforms that people are using.
They've just taken that goodwill that they were building on, and chucked it out the window, because now they're giving us just another browser, one which will take much longer to "trickle down" into the main browser population. Their gift of the shiny red apple turns out to have a worm in it.
No, this sucks. In every possible way, this sucks. This decision guarantees a future where our work just got harder. I see nothing good in this decision for anyone but Microsoft; it certainly isn't in the users' best interest, nor in the best interest of the web or the quality of the web on IE platforms. Nobody's going to care about new features in IE7 when they're still stuck supporting IE6, and Microsoft deserves the compatibility it will inevitably end up with.
- A bunch of developers finds a bunch of bugs and fix it in their source base.
- They hand you their source base, along with loads of information on where the bugs are, and patches that you can't integrate into CVS HEAD.
And the KHTML team is sitting around bitching about the fact that KHTML != WebCore anymore, and how none of the patches can be run against HEAD...
Ok, I was *at* Netscape at the time. I have no doubt that he and his team continue to bust their asses to ship good code, and they're passionate about doing so.
That is not to say that they:
1) Should feel restricted to KHTML's API. That's not in Apple's best interest, and they're not doing this *for the KDE team or organisation*. It's also not fun - they don't run Linux desktops, or KDE, and don't feel like re-entering Netscape's cross-platform hell.
2) Is KHTML nice and segregated? The whole reason WebCore happened was that KHTML was littered with KDE calls. Now the KHTML team is complaining that the WebCore code is littered with Mac API? Imagine my shock. Really.
3) A bunch of people just gave you a ton of information, bug reports, and example code you can *LIFT OUT AND REWRITE*.
Lazy? You're damn right you are. Disillusioned? Yeah, I'll bet. Apple didn't add developers to the KDE project - they added them to Safari. Any idiot can tell *from the starting point* that the only way the browser would happen was to do in WebCore what the KDE team did in KHTML; utterly fail to abstract platform-specifics from the rendering engine.
Personally? I could wish that some big commercial development house would take an open source product I was on, commercialise the development, submit its source code quarterly for me to scavenge for ideas and code where possible, and for it to remain legal to do so.
Is it "ideal"? What's "ideal"? A bunch of other people bend over backwards to make your codebase a nicer place to live in, so they can throw away their deadlines, fix the fact that you didn't separate out the platform dependency in the first place, and burn money on things in the codebase that don't have *any* outward impact except to make it easier for someone else to suck up the code into their tree?
I'll bet you're frustrated. All those damn clouds keep getting in the way of your panoramic view.
It may not be perfect - but it's more than just a little better than nothing; it's actually a hell of a lot of time and effort spent to give back to the community. Even if, in this specific instance, what's given back isn't instantly reusable by that community.
Meanwhile, you can go back to KDE. Not a bad product, but strangely enough, it's hard to run KDE applications without running KDE. It's hard to develop a KDE application that would/could. If anyone has experience with writing applications in an environment that has to cross APIs with fundamental differences in how they perform simple actions, it's the person you're accusing of... of what? Of not being "helpful enough"? Of not being a KHTML team member? Of not being an Apple employee paid to work on a KDE-specific project?
I'm having a really hard time imagining what the fuck is going on in your head, and I'm just not sure it's worth bothering; I suggest you start a rock band and burn off some of that angst on teenagers who are more likely to think that every word that comes out of your mouth is gospel, rather than the drivel it sounds like to those of us of older generations.
Concurrent with development of 3.0, and slated for a post-3.0 release, is a complete early preview of J2SE 1.5 support, codenamed "Cheetah", last release 2004/05/17.
http://dev.eclipse.org/viewcvs/index.cgi/%7Echec ko ut%7E/jdt-core-home/r3.0/main.html#updates
Instructions are there for downloading and maintaining the most recent version of Cheetah via the Eclipse Update Manager, which will install and update any installed version of this plugin once installed.
Currently supported include JCK 1.5 compliance, claiming, at the time of writing, 97.32% (271 test failures remain) compliancy; broad support for most of the generic types functionality (except covariance), and support for the enhanced for loops (but missing autoboxing, enumerations, static imports, metadata.)
It is unfinished; it won't make 3.0 release, but will hopefully reach feature completion around the time that JDK 1.5 is actually released.
Part of the point behind Project Liberty, and one of the reasons that Passport hasn't worked, is that people aren't necessarily comfortable with the idea of a 'centralised' authentication system for the whole of the planet.
Passport assumes that everyone who wants centralised authentication is happy to have this information be held/known to Microsoft.
Liberty assumes that individuals are only interested in centralisation of information across closed user groups; either:
1) A single site, made up of multiple services, is interested in acting as a cohesive single whole (for example, a login that logs you in to the whole of OSDN, rather than just Slashdot), or
2) A single site is interested in sharing its identities with suppliers; for example, your corporate intranet allowing their absence management, healthcare, stock options, and other service providers to allow you to log into that corporate account using your intranet username/password.
They're completely and utterly different goals. Passport, arguably, has no value in a modern society where people know full well how these identities can be used; Liberty is a more realistic usage scenario, in a multitude of ways.
Liberty is still young; while the software is getting quite good, it's still a hassle to set up an Authentication Provider or turn your site into something that can support the liberty Service Provider API. This will change. It will work and survive solely because it doesn't need internet users, as a whole, to accept it. It works on the principle that people who have a need to unify their authentication systems, without writing crappy little APIs, can do so, in the small scale, at the level where it can actually see benefits.
1) Integrate remote audio into all media apps in Mac OS X. What's good for iTunes is good for DVD player and QT; hell, it should be possible, on the desktop, to select a remote audio "AirTunes" connection as your standard audio output, with a CoreAudio interface, so that we can use things like Detour to choose the audio for any part of our system to go there. At minimum, though, it should cover all consumer media apps, and should be made open to Real and Microsoft ( if they *ever* release another version of WMP, that is... )
2) Integrate it into a next-gen iPod. If someone comes over with their iPod, I want them to be able to select my stereo and play music. It's a great idea, and it's just yet another reason why the iPod needs WiFi.
3) While you're at it, allow people to put their iPods into "broadcast" mode while they're listening, and let us select the audio from any other iPod in the area. I'm not saying I want to browse their collections - I just want the opportunity to listen to what someone else is listening to. If we can do more than that, great, but I'd settle for a live stream.
4) Pass out this technology to all the games console folks. They can choose whether they decide to include it in their console, turning each console into an AirTunes port I can select, or decide to allow you to select an AirTunes port as the game audio port.
The benefits of this stuff won't really be there until absolutely anything can use it; open it up.
ccTLDs are indeed automatic - any nation officially recognized with the two-letter ISO code has the ability to get a TLD, and as you can see, one already exists.
Here's the trouble.
All ccTLDs, by their very nature, are a three-way agreement: a government, who actually owns the TLD; an operator, who operates the TLD, and ICANN, who provides rules and regulations. A previous Iraqi government agreed that the ccTLD operator was going to be the Texan company; however, they are now essentially demanding to be re-provided control. On the other hand, they will have existing contracts with the ccTLD that limit it - and those, if binding enough, could be difficult to break.
Their argument, as always, is that they're a new government. A great many groups, across the world, would indeed love to get their hands on the TLD; so there's legal processes to take control over the TLD and become the official government responsible for it, as well as all of the legal wrangling with said Texan company, which probably has wholly unreasonable contracts with the previous government which are likely to still be legally binding.
Asking ICANN to step in is a bit foolish, IMO - there's nothing that ICANN can really do to strip the Texan company of its ownership of the domain. Governments fought hard in the GAC, under Twomey, the current man at the top of ICANN, but then at the top of the GAC itself, to draw careful lines in the sand over what ICANN could and couldn't involve itself with.
And have no doubt - with the way that the US government has handed out posts in the Iraqi government to contract out the airwaves, telecommunications, and other government contracts, even if we have this battle now, there's no doubt that all of these contracts will eventually get harsh reviews by a truly independent Iraqi government when those posts are relinquished back under the control of the Iraqi government in five years time, the length of control the U.S. will retain over those areas. That's "sovereignty" for ya - 'you can run your country, but we keep control over your resources'; keep the oil, but we keep everything else.
After all, they rebuilt it, right? Doesn't matter if they blew it up first.
If you don't like it, don't use it. Plain and simple.
Some of us, for example, route audio from different applications to different places; when I play music or games, it comes out through my audio system and the amplified speakers - when an e-mail dings at me, it comes out through an internal speaker.
Haxies like Detour, which provide real, interesting function, which is useful for any pro-audio guy with a lot of very loud audio hardware that you don't want system beeps playing over, is fundamentally interesting - moreso if you've got more than one set of audio outputs.
So, before people go off badmouthing how awful it is, they should think twice: that same code injection technology enables everything from Shapeshifter to reskin your UI to useful functions like being able to reroute your audio away or into your pro-audio equipment on an application-by-application basis.
In other words: despite everyone's nasty opinions, it provides a useful service to those of us with unusual requirements of our systems.
Basically, Fugu is a non-poisonous fish; aside from the organs which store and process various poisons, it's fine to eat.
What happens when you eat it, of course, is pretty normal for such a thing - nothing. It's a bit of an unusual texture, but if you're into sushi enough to want to try fugu in the first place, it's not so unusual as to be unique.
What IS unusual is the toxin. When taken in large doses (large, for example, being a whole fish, or even a chunk of liver) it's deadly. It doesn't actually take much toxin to kill; however, the trick is to have enough toxin in your fugu to make your lips and tongue just slightly numb. Fugu is a strange experience mostly because you're ingesting small amounts of poison.
That's why good fugu is so hard to find - what you're *not* looking for is fugu sans all toxin. What's worse yet is that it's very difficult to tell which fish will be incredibly poisonous, and which will not - there are people who have eaten chunks of the liver and had only mild effects; there are others who have eaten a sliver and died.
What's sure, though, is this: Should you die as a result of eating fugu, the man who prepared it will never work in a fugu restaraunt for the rest of his life.
Slashdot Mirror
Walk around in his garden blowing 'breath of life' into anatomically-correct mud sculptures of men?
Imagine Mary walking in on *that* little scene.
I'm sorry, but I need to call you on that.
An expert's opinion ought to be worth more than a layman's. If someone goes to congress, in an expert capacity, to discuss an issue, they are not doing so on the grounds of being your average punter - they are doing so under the auspices of fundamental expertise on the issue being raised.
That is not the same as your mom calling your Senator on the same issue. There's democracy and there's tyrrany of the majority; expertise needs to matter. The whole point of policymakers is that they're *not* the people who are experts on an issue; simply people whose job it is to find the experts on those issues and navigate a policy.
Strikes me as a lot closer to the civil war. A lot of good developers, our brothers and sisters in the South and North, are going to get hurt in the process of fighting a war that neither side can actually "win" - resulting in one side that claims victory, but changes none of the behaviour that led to that war's existence in the first place.
The civil war did not end slavery; Microsoft's licensing war will not end intellectual property practices.
WebKit is now pretty different than KHTML. Adding in platform-specific support is now much easier. cia.webkit.org points at cia.vc's entries for WebKit, where you'll find checkins active on GTK and a re-port in progress to take WebKit back to Qt. There's also some Wx work going on.
I suspect, shortly, we'll be seeing a mass import of code for Win32, and sometime after iphone release, for it.
Ok, let's change the rules a bit. There are lots of very good games that you can probably scrape by on, even with some arthritis. You'll always be able to enjoy Half-Life 2, probably, as well as most other FPSes.
:)
Let's try this: There are several reeeeeeally good games out there that, even without arthritis, left my hands sore and painful. Blame the controllers, if you like - but play them now, when the pain won't be excruciating, rather than later.
Metroid Prime and Metroid Prime 2 both qualify; keeping the buttons depressed during very long periods of time for targeting left the fingers of my left hand feeling like I had bent them the wrong way around. They're great games, both gamecube games, and you should play them both. If you're worried about difficulty, grab an Action Replay and cheat your way through it, so you get the whole experience.
I'm struggling to think of others offhand - but they definitely exist. There are some great games out there that, due to controller layout and gameplay behaviour, leave you in pain after long gaming sessions. Play them now and get them out of the way, and never look back.
Then pick up a Wii and say goodbye to thumbsticks. There's always keyboard/mouse on the PC as well.
And good luck; I'll make sure to request that the question be reposted in 10 years time, when I'll be where you are.
Ultimately, the problem with variety isn't player confusion - though that surely is a very real problem for players.
The problem with offering variety is the need to ensure that variety doesn't lead to unbalanced play. Someone else hit it on the nose - huge amounts of variety leads to huge amounts of testing. It doesn't matter whether or not some builds work well and others don't - while ideally you want to avoid that kind of situation, it's not actually going to damage the game itself, just the players' experience.
The problem is with unbalanced characters created for the purposes of farming the world. Game developers have to work hard to balance and carefully tune the rate at which resources can be plundered from the world, or the whole economy goes up in smoke. For those who have been in a game where the economy has done just that, they can attest how hard it is to play a game where the economy is buggered.
Ultimately, it's all about the virtual Benjamins. The further a game gets from needing to maintain an economy and control the rate of loot acquisition, the more flexibility it has to experiment with variety.
It's a valid point, even if we're not listening properly. WiFi is pretty much de-facto now - you can expect most people to want WiFi.
And yet, the support for it is *crap*. Unlike almost everything else, where the open source community have come up with good solutions (and in some cases, in partnership with manufacturers) to these problems, Linux WiFi sucks.
Buy a graphics card tomorrow; it probably works. People who know little will be able to use it.
Buy a sound card tomorrow; it probably works. Ditto.
And go all the way down the parts list, including physical network cards, and you'll have the same response. Go within ten feet of WiFi, and you're gambling - there's a 50/50 chance it works. And if it does work, it may require you to do something rather unusual - to use Windows drivers, because there aren't any for Linux.
Honestly? ndiswrapper is the worst thing to happen to Linux OSS in a long time - it's meant that people can wave their hands and call it "solved", without actually solving it for most of the population of non-technical users.
It's a shame, really, that we're at this crossroads so late - yet, here we are, and it's fourth and inches from ndiswrapper being EOL. With no general solution for how to improve WiFi for the majority of users once it goes.
Let's face it folks: Something needs doing, and the OP has a point, even if he didn't know he was making it.
They're being slashdotted. Not directly, of course, as nobody can just click to log in - but *everybody* is running over to the server and creating toons on it in order to go and see the new content. People had been warned that it was happening, everyone knew that this was going to end up being the fate of the first server to open the gates.
What can you do when 5+ million players all want to see the new content, but their own server's gates aren't open?
26 million rows = broken MySQL system.
It just doesn't cope. It's fine if you've got no data to speak of; it's great when the sizes of what it's working with is small.
IT TAKES 24 HOURS OF UNWRITABILITY TO MAKE A DAMN BACKUP, FOLKS.
MySQL was the biggest mistake I ever made. I had the option of choosing Postgres on an older version of the software, or MySQL on the latest, and I've been regretting it ever since.
The fact is this: I've used it for stuff when the amounts of data are small, and it's brilliant - but if you need to keep a lot of information, you're screwed - run, don't walk, to the nearest vendor and get something decent, because MySQL just can't cut it. It's missing too much in too many places.
Now, I haven't used 5. I'll have to, because 4 sucks, and 5 can't be worse - I can only hope that 5 gets rid of the worst of my problems; it will probably stay slow and unresponsive, and continue to take an hour to generate a report, but I can at least pray that perhaps, if I'm lucky, I can get a backup out of it without taking down the system.
No matter how good you think it is; no matter how fast you think it might be... don't pretend it scales up to the kinds of loads the commercial vendors can handle. There's a reason the big boys cost big money, and despite popular opinion, it's not all just leeching money out of your pocket. MySQL doesn't do big well.
Communigate.
Full exchange compatibility with an exchange connector you install - but it *does* work, and has for ages.
Does everything well, on any OS you want. Sorry - I can't see *any* reason to run Exchange. None. Not when the competition is just *so* much faster.
TCP_ would be the reason that the TCP related portions of his tests - you know, "apache", and "mysql", and stuff - sucked.
As for the "microkernel"... You do know it's not Mach in microkernel mode, right? It doesn't mean it doesn't have its problems, but it does mean that Mac OS X doesn't have a microkernel.
There are bits that suck - but these aren't them.
OK, no, that's my point - you're missing the point.
If the point of the article is "why mac os x is a poor server install", going around talking about a bunch of untuned applications is a poor way to do it.
Most of us who do high-performance servers aren't interested in whether bog-standard package installs do well, because we don't expect any platform's bog-standard install to be good enough.
Every kernel needs to be tuned for performance. Every kernel, therefore, needs to be tunable. Talking about where Mac OS X *isn't* tunable, therefore, makes for a good way of talking about where the flaws are.
Knowing that it's got major problems with its TCP implementation is another good way of knowing what the true problems will be; knowing about the high cost of context switches, and syscalls, on the platform...
And going into it, that's what I'd expect an article to talk about. Talk about the *real flaws of the OS*.
Running Apachebench? What does that tell me about the OS? All it tells me is that some idiot thinks that an RPM install of Apache is good enough to handle high volume content delivery - and alone, on an off-the-cd install of Redhat, it's not. Or any other platform. If someone else's support-tuned, 'good enough to ensure the vendor doesn't get calls about stability' is good enough to equate to a high-performance environment where high performance is actually *required*, then we're not talking about the same things - and you might as well buy anything.
People who actually need to run high performance systems don't expect good performance out of package installs. They're untuned. You *expect* to build it (for example) for a G5-only optimized system, tuned for your hardware, on the latest compiler you can get your hands on and verify stability of. Not run it on whatever was built to make some support bod's job easy.
So for people intending to *actually make a decision about the OS as a server platform*, this article is actually a sham.
Having said that, I think that Darwin is a pretty crappy kernel for high performance applications. So, as the subject says, there are problems, but these aren't them.
Fix the latency problems across the user/kernel boundary. Reduce dramatically, please, the cost of context switching that makes heavily threaded applications crawl. Do something about the bugs in the TCP implementation, which prevent most applications expecting Linux-like behavior out of the socket system to *not suck* when run on Darwin.
But don't cry about how the package installs aren't good enough - because they're not 'good enough' on anybody's platform when it comes to a high performance delivery system. If they were, people wouldn't run Gentoo.
If that's what you're expecting, then you're going to be disappointed to find out that every OS vendor ships bugs in their server operating systems, and that every application developer ends up having to do work to make sure that their applications avoid those bugs.
All of us.
So this whole "OS X sucks as a server" thing can be justified on a lot of grounds, but NOT THIS ONE. Cry more about how bog standard vendor installs aren't high performance monsters. Cry more about how application developers shouldn't have to work around bugs in vendor operating systems.
Then go back to Basic on your Colecovision, because that's probably the only OS I can think of that didn't ship with one.
For just a second, step back.
./configure && make install.
./configure? Are we talking about "Apache being slow", or "the bog standard install being slow"?
Apple's not special, and just like every other vendor, they ship bugs. And just like every other vendor, they build, test, and ship the applications that come out in a pretty identical way you get to when you
So, here's the question: Are we talking about the operating system, or someone's ability to run
Because, for a moment, I thought the whole point of the article was to point out the huge, gaping flaws in the kernel - and someone with the right nail (let's point out the flaws in a kernel) ended up with the wrong hammer (let's run a bunch of applications that don't behave well in standard installs or are old enough to be missing important dev fixes.)
Nowhere did I strain to stick my nose up apple's arse - yet your reaction says it all. You're not actually interested in the point of the article, either, and neither was the author.
You're just looking for a way to stick it to Apple for being crap.
Congratulations, you're a winner - Apple's just another OS vendor, shipping just another set of unusual bugs around, just like the FreeBSD it's built on. It's got a 'colourful' TCP implementation, just like FreeBSD, it's got bugs, just like FreeBSD, and it's got its problems with overhead on PPC, just like FreeBSD.
And Linux 2.4, which also had that TCP bug for a while. And 2.6, which now has a different one. Because, quite frankly, if we all wanted the perfect OS for performance, we'd all be running Solaris, wouldn't we. They don't *ever* get bugs in their kernel.
Wanker.
What a stunningly dumb article. Great high-level point of view on what problems can bubble up and look like, but no low-level understanding of what the problems *are* at all.
For example:
- Under 10.4, you need to ensure sockets get TCP_NODELAY, and that you don't try and use corking via TCP_NOPUSH or TCP_CORK. Memcached users are watching stuff *crawl* when they hit it, depending on the buffer size you happen to be using.
- Whinging about thread creation overhead ignores the fact that just about everything that uses heavily threaded environments use a thread pool and/or worker system - so thread creation overhead is pretty much a red herring in most app design. Sure, it's not brilliant that it's there, but it's also pretty pointless to talk about.
- As anyone who used poll() under heavy load knows, Panther could core dump; Tiger has improved, but it's poll() implementation is still suffering.
- There is, actually, a hidden cost on Macs - POWER state load/store is a lot more expensive, and the context switches are much higher. Tasks which cross the kernel barrier heavily do indeed pay a higher cost on the mac. This requires that folks who are used to 'cheaper' system calls think a bit more about how they can efficiently move their data in the smallest number of syscalls.
- And let's not forget to mention the exponentially more expensive cost of misaligned data access on PPC, easily invoked accidentally in code.
I mean, even once you get past the worse-than-one-might-want performance of the poll() causing problems, you've got the critical problem with TCP latency stepping in.
Strangely enough, all the tests they did that actually show problems are either known bugs, with known workarounds, or are known differences in behavior...
At some point, someone needs to call a spade a spade - was Apache built using TCP_CORK? You betcha. Was he using a fixed version of MySQL? Nope. Did the form of the tests for MySQL also succumb to the TCP_CORK problem? Almost guaranteed.
A poor test. Next time, pay some monkey to *write some code* if you're trying to prove the 'cost of latency'; if you're trying to prove that most Unix software isn't brilliantly optimized to work around issues which have existed on the mac for some time? Well, everything takes time, doesn't it.
On the patentability: Yes, there's oodles of parallel prior art.
On the game itself:
Mustn't be missed. The sanity system is *effective*; it really honestly does warp the player's perspective, make it honestly difficult to know what's real and what isn't, and does actually inspire a creepy sense of dread.
It makes you go out of your way to not create the situations that end up with you being insane. Loss of sanity happens through a few different ways, but basically it's "do something nuts, and go nuts; get hit by something freakish, and go nuts".
If a creature gets the jump on you, your sanity drops. If you get the first shot in, you keep your sanity unless it hits you physically - and then your sanity drops. Physical damage gets fixed, but the psychological damage can only be fixed through a different mechanism.
It's absolutely brilliant, and makes for *riveting* gameplay. Patents like this, which make it harder for people to innovate gameplay, shouldn't be allowed, IMO, if they're overly broad. It's too good an idea to only end up in one game from one company on one system - something like this belongs all over the place.
It's just brilliant.
We moved most of our searching out of SQL and into Lucene for a variety of reasons; and this book has been useful, not just in figuring out good ways of writing those queries that maintain microsecond response times (which Lucene is absolutely brilliant at), but...
- Good ways of doing batch indexing operations
- The purpose of the compound document format
- How to generate explainers for searches
- Field-specific handling, and how to do it well
- Ideas like metaphone replacement (soundex) and use of WordNet to integrate a synonym database into search queries
- When to use CachedFilters to remember complex filters
- Ideas for how to build "Things Like This" lists
- Ideas on autocategorisation and geographic searches
- Named Entities and LingPipe - making the search system recognize "proper names" for things
- NGRAM recording to gauge word frequency and search terms to detect misspellings and offer alternate searches ("Did you mean XXX"?)
etc.
If you're building a search engine, this isn't just a useful resource on implementation - you probably don't need a book for that. What it is brilliant at is providing a lot of ideas that can take you to the next stage - how to build something really cool with your information, and not just a dumb text field search.
For that alone, the book was worth the purchase price, for me. It's now well annotated, and the back pages are full of references to ideas that can be used in our own implementation, and the page numbers to use to get there.
Highly recommended for anyone who needs something more than what a Google search of your site provides.
I mean, let's be frank. There are a *horde* of basic bugfixes that are meant to be in IE7; things which will bring it into compliancy and free an awful lot of people using an awful lot of broken implmentations.
This was supposed to be a real gift and boon to the Web - something Microsoft was finally going to do right. They were going to release a version of IE which fixed most of the glaring bugs, fixed PNG transparency, brought forward a lot of basic technology that all of the other standards-based browsers have.
And now? Now they're not releasing it for the majority of platforms that people are using.
They've just taken that goodwill that they were building on, and chucked it out the window, because now they're giving us just another browser, one which will take much longer to "trickle down" into the main browser population. Their gift of the shiny red apple turns out to have a worm in it.
No, this sucks. In every possible way, this sucks. This decision guarantees a future where our work just got harder. I see nothing good in this decision for anyone but Microsoft; it certainly isn't in the users' best interest, nor in the best interest of the web or the quality of the web on IE platforms. Nobody's going to care about new features in IE7 when they're still stuck supporting IE6, and Microsoft deserves the compatibility it will inevitably end up with.
Let's be frank, folks.
- A bunch of developers finds a bunch of bugs and fix it in their source base.
- They hand you their source base, along with loads of information on where the bugs are, and patches that you can't integrate into CVS HEAD.
And the KHTML team is sitting around bitching about the fact that KHTML != WebCore anymore, and how none of the patches can be run against HEAD...
Ok, I was *at* Netscape at the time. I have no doubt that he and his team continue to bust their asses to ship good code, and they're passionate about doing so.
That is not to say that they:
1) Should feel restricted to KHTML's API. That's not in Apple's best interest, and they're not doing this *for the KDE team or organisation*. It's also not fun - they don't run Linux desktops, or KDE, and don't feel like re-entering Netscape's cross-platform hell.
2) Is KHTML nice and segregated? The whole reason WebCore happened was that KHTML was littered with KDE calls. Now the KHTML team is complaining that the WebCore code is littered with Mac API? Imagine my shock. Really.
3) A bunch of people just gave you a ton of information, bug reports, and example code you can *LIFT OUT AND REWRITE*.
Lazy? You're damn right you are. Disillusioned? Yeah, I'll bet. Apple didn't add developers to the KDE project - they added them to Safari. Any idiot can tell *from the starting point* that the only way the browser would happen was to do in WebCore what the KDE team did in KHTML; utterly fail to abstract platform-specifics from the rendering engine.
Personally? I could wish that some big commercial development house would take an open source product I was on, commercialise the development, submit its source code quarterly for me to scavenge for ideas and code where possible, and for it to remain legal to do so.
Is it "ideal"? What's "ideal"? A bunch of other people bend over backwards to make your codebase a nicer place to live in, so they can throw away their deadlines, fix the fact that you didn't separate out the platform dependency in the first place, and burn money on things in the codebase that don't have *any* outward impact except to make it easier for someone else to suck up the code into their tree?
I'll bet you're frustrated. All those damn clouds keep getting in the way of your panoramic view.
It may not be perfect - but it's more than just a little better than nothing; it's actually a hell of a lot of time and effort spent to give back to the community. Even if, in this specific instance, what's given back isn't instantly reusable by that community.
Meanwhile, you can go back to KDE. Not a bad product, but strangely enough, it's hard to run KDE applications without running KDE. It's hard to develop a KDE application that would/could. If anyone has experience with writing applications in an environment that has to cross APIs with fundamental differences in how they perform simple actions, it's the person you're accusing of... of what? Of not being "helpful enough"? Of not being a KHTML team member? Of not being an Apple employee paid to work on a KDE-specific project?
I'm having a really hard time imagining what the fuck is going on in your head, and I'm just not sure it's worth bothering; I suggest you start a rock band and burn off some of that angst on teenagers who are more likely to think that every word that comes out of your mouth is gospel, rather than the drivel it sounds like to those of us of older generations.
Just so that everyone knows:
c ko ut%7E/jdt-core-home/r3.0/main.html#updates
Concurrent with development of 3.0, and slated for a post-3.0 release, is a complete early preview of J2SE 1.5 support, codenamed "Cheetah", last release 2004/05/17.
http://dev.eclipse.org/viewcvs/index.cgi/%7Eche
Instructions are there for downloading and maintaining the most recent version of Cheetah via the Eclipse Update Manager, which will install and update any installed version of this plugin once installed.
Currently supported include JCK 1.5 compliance, claiming, at the time of writing, 97.32% (271 test failures remain) compliancy; broad support for most of the generic types functionality (except covariance), and support for the enhanced for loops (but missing autoboxing, enumerations, static imports, metadata.)
It is unfinished; it won't make 3.0 release, but will hopefully reach feature completion around the time that JDK 1.5 is actually released.
Part of the point behind Project Liberty, and one of the reasons that Passport hasn't worked, is that people aren't necessarily comfortable with the idea of a 'centralised' authentication system for the whole of the planet.
Passport assumes that everyone who wants centralised authentication is happy to have this information be held/known to Microsoft.
Liberty assumes that individuals are only interested in centralisation of information across closed user groups; either:
1) A single site, made up of multiple services, is interested in acting as a cohesive single whole (for example, a login that logs you in to the whole of OSDN, rather than just Slashdot), or
2) A single site is interested in sharing its identities with suppliers; for example, your corporate intranet allowing their absence management, healthcare, stock options, and other service providers to allow you to log into that corporate account using your intranet username/password.
They're completely and utterly different goals. Passport, arguably, has no value in a modern society where people know full well how these identities can be used; Liberty is a more realistic usage scenario, in a multitude of ways.
Liberty is still young; while the software is getting quite good, it's still a hassle to set up an Authentication Provider or turn your site into something that can support the liberty Service Provider API. This will change. It will work and survive solely because it doesn't need internet users, as a whole, to accept it. It works on the principle that people who have a need to unify their authentication systems, without writing crappy little APIs, can do so, in the small scale, at the level where it can actually see benefits.
1) Integrate remote audio into all media apps in Mac OS X. What's good for iTunes is good for DVD player and QT; hell, it should be possible, on the desktop, to select a remote audio "AirTunes" connection as your standard audio output, with a CoreAudio interface, so that we can use things like Detour to choose the audio for any part of our system to go there. At minimum, though, it should cover all consumer media apps, and should be made open to Real and Microsoft ( if they *ever* release another version of WMP, that is... )
2) Integrate it into a next-gen iPod. If someone comes over with their iPod, I want them to be able to select my stereo and play music. It's a great idea, and it's just yet another reason why the iPod needs WiFi.
3) While you're at it, allow people to put their iPods into "broadcast" mode while they're listening, and let us select the audio from any other iPod in the area. I'm not saying I want to browse their collections - I just want the opportunity to listen to what someone else is listening to. If we can do more than that, great, but I'd settle for a live stream.
4) Pass out this technology to all the games console folks. They can choose whether they decide to include it in their console, turning each console into an AirTunes port I can select, or decide to allow you to select an AirTunes port as the game audio port.
The benefits of this stuff won't really be there until absolutely anything can use it; open it up.
ccTLDs are indeed automatic - any nation officially recognized with the two-letter ISO code has the ability to get a TLD, and as you can see, one already exists.
Here's the trouble.
All ccTLDs, by their very nature, are a three-way agreement: a government, who actually owns the TLD; an operator, who operates the TLD, and ICANN, who provides rules and regulations. A previous Iraqi government agreed that the ccTLD operator was going to be the Texan company; however, they are now essentially demanding to be re-provided control. On the other hand, they will have existing contracts with the ccTLD that limit it - and those, if binding enough, could be difficult to break.
Their argument, as always, is that they're a new government. A great many groups, across the world, would indeed love to get their hands on the TLD; so there's legal processes to take control over the TLD and become the official government responsible for it, as well as all of the legal wrangling with said Texan company, which probably has wholly unreasonable contracts with the previous government which are likely to still be legally binding.
Asking ICANN to step in is a bit foolish, IMO - there's nothing that ICANN can really do to strip the Texan company of its ownership of the domain. Governments fought hard in the GAC, under Twomey, the current man at the top of ICANN, but then at the top of the GAC itself, to draw careful lines in the sand over what ICANN could and couldn't involve itself with.
And have no doubt - with the way that the US government has handed out posts in the Iraqi government to contract out the airwaves, telecommunications, and other government contracts, even if we have this battle now, there's no doubt that all of these contracts will eventually get harsh reviews by a truly independent Iraqi government when those posts are relinquished back under the control of the Iraqi government in five years time, the length of control the U.S. will retain over those areas. That's "sovereignty" for ya - 'you can run your country, but we keep control over your resources'; keep the oil, but we keep everything else.
After all, they rebuilt it, right? Doesn't matter if they blew it up first.
If you don't like it, don't use it. Plain and simple.
Some of us, for example, route audio from different applications to different places; when I play music or games, it comes out through my audio system and the amplified speakers - when an e-mail dings at me, it comes out through an internal speaker.
Haxies like Detour, which provide real, interesting function, which is useful for any pro-audio guy with a lot of very loud audio hardware that you don't want system beeps playing over, is fundamentally interesting - moreso if you've got more than one set of audio outputs.
So, before people go off badmouthing how awful it is, they should think twice: that same code injection technology enables everything from Shapeshifter to reskin your UI to useful functions like being able to reroute your audio away or into your pro-audio equipment on an application-by-application basis.
In other words: despite everyone's nasty opinions, it provides a useful service to those of us with unusual requirements of our systems.
Basically, Fugu is a non-poisonous fish; aside from the organs which store and process various poisons, it's fine to eat.
What happens when you eat it, of course, is pretty normal for such a thing - nothing. It's a bit of an unusual texture, but if you're into sushi enough to want to try fugu in the first place, it's not so unusual as to be unique.
What IS unusual is the toxin. When taken in large doses (large, for example, being a whole fish, or even a chunk of liver) it's deadly. It doesn't actually take much toxin to kill; however, the trick is to have enough toxin in your fugu to make your lips and tongue just slightly numb. Fugu is a strange experience mostly because you're ingesting small amounts of poison.
That's why good fugu is so hard to find - what you're *not* looking for is fugu sans all toxin. What's worse yet is that it's very difficult to tell which fish will be incredibly poisonous, and which will not - there are people who have eaten chunks of the liver and had only mild effects; there are others who have eaten a sliver and died.
What's sure, though, is this: Should you die as a result of eating fugu, the man who prepared it will never work in a fugu restaraunt for the rest of his life.