I don't disagree. Apple should support the full SAMBA spec.
But, please enable encrypted passwords. Not only will it get Tiger to interface with your server (small bonus) but it helps increase the security of your LAN. The last thing you'd want to do is give an attacker your password for free, with no effort at all. Then they wouldn't even have to hack your mac, they'd just use the password you graciously gave them.
This is for the good of the Internet. Get with it.
Ehh, Apple pushes for releases harder than KHTML does, because Apple has deadlines to meet for the larger product.
KHTML is an incredibly clean framework. It's hard not to look messy by comparison. It's not terribly fair though, WebCore is not a "messy" framework by any means.
Your "cookie" batch metaphor doesn't apply. First, it makes it seem like Apple is taking finite resources that other, more polite individuals perhaps, could use.
This is not the case.
Your metaphor also implies that somehow the KHTML is project is worse off for their involvement in Apple.
This is also not the case, unless you consider it from a PR standpoint, and then the point is arguable.
Fork Shmork. If they were forking it, they should have have been more forking forthcoming. Instead, they make it seem like they're working with the oss community on projects - they release all these changes and everyone think's it's great, but all the changes are useless for anything but WebCore.
Apple's media engine hasn't really been generating this happy-hand-in-hand image. The media hype by fanboys has. I've been guilty of believing it myself, and I feel embarassed for being so naive.
Well, first, besides the newfangled ACiD test smiley face, Konqueror is a very good rendering engine. It renders most pages as good as Firefox, somtimes a little nicer. The font rendering in Konqueror tends to look better on my systems then they do in Firefox/Mozilla.
ACID2 Test aside, WebCore renders faster and more correctly. This is nothing to be ashamed of. KHTML trades off features for code correctness. This is their decision. You do it fast and accept some ugliness, or you do it slowly and more beautifully.
So, we should just throw in our hats and all write Microsoft-caliber software? We should do away with pride in our work, in getting it done right, in effecient executables because you think it's out-dated?
No. That's not what I said. What I said was that Agile methodologies suggest a faster release cycle, with refactoring being constant, and done as needed. I am not a KHTML developer, but speaking with one and listening to their public statements gives me the impression that they do not like this approach.
WebCore is not beautiful, but the KHTML team makes it sound like the software wasn't released, but instead clawed a bloody trail free from its unwilling host body and now assails innocent teens who are making out in the Old Lake House. It is not that bad at all. Certainly, it's above the standards of most software released today.
I think the whole idea that you need to ship, ship, SHIP software is showing it's age. I salute the KHTML team for wanting the code to be clean and effecient and retaining the things that make it good. Small footprint, efficient code.
Perhaps you should, I dunno, catch up with the times. It's not about Ship Ship Ship, it's about keeping a sustainable release rate and measurable progress. Safari does what it needs to do, and it's not a horrible tangle of code (it is undeniably less clean that KHTML, I've worked with both and I admit WebCore could use some refactoring). That's part of commercial software.
I guess the whole "improvement" is subjective. They might have improved the way the thing renders some things but at what cost? According to the KHTML folks, the apple improvements came at too high of a cost. Messy patches and OSX specific code.
You're right that it's all got a subjective cost. I find anything relying Qt to be utterly corrupted. That's the point of this excercise, and part of my statement about your unreasonable expectations.
I didn't have unresonable expectations. I expected Apple to behave like decent netcitizens. They should have made their intentions clear from the start (a full fork, see ya KHTML.) If they really intended to work with the KHTML team they could have easily made it work. Other companies do.
Not only do I think that Apple didn't ever offically come out and say, "We're going to go hand-in-hand with the KHTML devs!" But I also submit that project focuses change over time. WebCore's current incarnation may not be something they envisioned when they began.
It's true that sometimes, you can strike it lucky and make good software quickly. This is not the norm. Often, we only understand what we really need after we've written something that we don't.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
Continuous attention to technical excellence
and good design enhances agility.
Simplicity--the art of maximizing the amount
of work not done--is essential.
Without question, software quality is important. But Agile developers accept that just "doing it right" is so difficult as to be impossible. Instead, we get the smallest slice of work that we can done, then refactor and iterate as needed.
The between-the-lines point here is that getting working and not-awful code now is the secret to success in the long term. Dozens of projects have proven this over and over. UNIX is probably one of the most famous examples, as suggested in the famous "Worse Is Better" essay.
Polishing code until it's perfect without new feature development is an excellent way to get outdated.
No - they're purposfully difficult to integrate back into KHTML. The apple patches don't include changelogs, they have too many references to closed-source apple API's and modified QT API's.. they'd fix bugs without consideration on other things it would break (some of which would be things apple didn't use so they simply didn't care.)
You make it sound like fiendish Apple Oompa-Loompas are conspiring to somehow shut KHTML down out of malice. This is not the case. Apple is simply starting to realize what you don't seem to want to realize. WebCore is a fork, and it's diverging from KHTML. Or maybe you do realize it, but just don't like it?
Which aspect? And why arrogant? The KDE devs WROTE the damned thing. It's their baby. They're not going to ditch their project for some bastard-child that Apple has created.
And the Apple devs have done enough work now that, quite frankly, they need KHTML less and less. It's called forking, and when one team works at a much faster pace than the other, the result is inevitable.
People percieve this as arrogant on the KDE team's part because, simply put, Apple has a better rendering engine now. Part of the reasoning behind the lack of kickback is not just the absence of a CVS branch or lack of changelogs, but because the KHTML code is very "clean" and correct. The Apple code suffers from time-to-market-itis. So, the KHTML developers don't want to go through the effort of backporting.
Quite frankly, the KDE folks' mentality is out-of-style in the Agile Development world.
Bullshit! Think about: You're a principal developer in designing a strong HTML renderer. You put a lot of time and effort into it. Along comes some big company that grabs your code, renames it, and puts it into their product publically. They submit some patches. Then, they basically stab you in the back.
Wait, you're implying Apple comes in, does a smash and grab on freely available code, then instead of improving it (which they did), you imply that they slapped a MacOSX front on it, called it their own, then gave you the finger.
That's wrong and you know it's wrong. If they did so little, why can't you backport the changes? Could it be, maybe, because they've made significant changes to the library, relying on their own APIs (just as KDE relies on KDE apis)?
Sounds to me like you had unreasonable expectations.
Apple is on record for offering to jointly attempt to make the important parts of WebCore cross-platform, similar to the situation with Gecko.
The KHTML team turned them down. They probably did so because it would shift the focus away from the KHTML they know and love and more towards the more realistic (but messier) WebCore, which they don't seem to want to do.
The KHTML team doesn't even seem to want many of the changes. Apple makes a product, and they don't care if they break small things to make deadlines. KHTML is a product of the opposite school, preferring to make a very small, clean codebase. The price of this is feature deficit.
This isn't about Apple being evil, or KHTML being snobs. It's about a project being forked. As time goes on, Apple has less and less to offer to KHTML. WebCore and KHTML are diverging, and people seem to be upset about this. I can't imagine why, this sort of separation was inevitable. Apple's best interests are served by leveraging their own excellent environment, and every time they do, they further exclude the KDE project.
Everyone is always using computers.
on
Johnny Can So Program
·
· Score: 2, Interesting
Learning programming is a waste of time.
Not at all. Even basic skills in programming give people tremendous advantages in modern society. While I agree that it'd be great to teach kinds more fundamental stuff like analytical skills, that's outside the scope of this discussion. I think we both agree that the education system needs to be reformed.
But, simply put, there are many opportunities that a programmer has in life that a non programmer doesn't even realize. The number of such opportunities goes up as the overall computer usage in society goes up. This is not like using a hammer. Most people do not use a hammer every day, because a hammer is a relatively specialized tool compared to a computer.
We need to teach programming earlier and better.
on
Johnny Can So Program
·
· Score: 3, Interesting
Part of the problem is how poorly american culture has adapted to the modern world of computing. Despite the fact that people use computers nearly every day in dozens of capacities, it's still considered an esoteric and specialist degree.
For example, look at how late in our educational system the process of programming education begins. Most "good" programmers I know were fooling around with code long before their schools ever even dreamed of introducing them to such concepts (usually around or before age 10, even!) Remember the Smalltalk project at PARC? They had children making animations, programs, games, and even simple applications. Obviously, children can understand it if you present it correctly.
Between this delay and the general American stigma against intellectualism, many of the programmers we produce are not terribly good at the job. Maybe they did it for the money (before the.com crash), or because they could get an associates degree at ITT (better than flipping burgers), or maybe they made some fast money making cheap ameturish webpages and now they think they can do anything (classic townie wannabe).
What we need to do is teach kids to program at an earlier age. We also need to stop being so concerned about teaching them a "low" level language first. Let's start with Python or Ruby. Let's have them doing things instead of wasting time making for loops or calcualting array medians. Start making network-enabled applications, making interactive websites, etc.
Then, let's combine that with their math courses. As they learn math, they can learn the corresponding ways to do it on a computer (when feasible).
That way, they'll already know if they like programing or not, and they'll be able to make intelligent and informed decisions about what direction to steer their life. I can't tell you how many people I watched drop out of our CS Pre-major in college because they didn't realize what CS really was.
Also, why don't we see more vocational programs for cheap coding work? Not to offend web designers, but there's an example of a career that could be considered for vocational schools.
America is having problems keeping up with their demand because our entire society is shaped to ostracise young people who are interested in the subject, and discourage them. Only the most persistant and passionate people make it through, leading to a vast gulf between a "good" software engineer produced in America and a "bad" wage-slave class coder.
If Sony doesn't care, then why exactly did they allow PSPs to run applications off of memory sticks at all? Why does the PSP have so many extra little features?
I've talked about this before. I suspect that Sony wants to generate an underground development movement with the PSP to help draw people to it. Handheld platform competition is brutal, but the hackability of the PSP really makes it stand out compared to the DS (and previous consoles).
Sony will still make money with licensed games, the UMD format is closed (albeit hacked) and the physical media is difficult to reproduce. Their model is safe, while at the same time allowing for an underground community to exist.
Err, uhh, so what you're saying is that it's correct for Safari to prompt me before downloading it and running it from a click (that "has an application" prompt is in Safari), but when you put a special meta-refresh, it shouldn't?
Why?
It's not a serious issue, the damage caused is minimal, but these kinds of tiny holes have a way of being part of a larger attack.
The fix is to make sure that Safari always prompts you before auto-install or safe open. Especially when it doesn't happen as the result of a GET (as in the example page, check out the refresh header at the top of the source, that's not cool).
I'm sure there are people out there who want reolving porn widgets on their dashboard. More power to them. What's key there is that they want and Safari needs to ensure that it always asks that question.
Thanks for the pointer. I actually do know about ATLAS and LAPACK. The reason I'm using the GSL is because of deployment ease. It's much harder to deploy fortran-based software than it is C-based software.
But it might be cool to distribute an ATLAS backend too.
Observations on Apple's GCC4 release
on
A Review of GCC 4.0
·
· Score: 4, Interesting
It isn't a huge deal for most people, but it seems like the new GCC is singificantly better at optimizing for the PowerPC now.
I've been working with the GNU GSL on my mac a lot, and I recently updated to Tiger. The first thing I noticed when I recompiled the GSL with Apple's modified GCC4.0 is the significant and noticable speed increase. With this intense math stuff, doing SVD on 300x200 matricies, and it's shocking how much faster it is. I went from 3-5 seconds down to less than one.
I am not going to post any hard numbers because I haven't rigorously compared them yet, but I'll make some formal comparisons this week.
Reasons? Well for one, Apple has a different set of coding standards and SCM tools. I know that the KHTML developers want CVS logs, but Apple just doesn't produce that kind of output.
Another would be that Apple gets to work with their own libraries. This sucks for the KDE group, but it's kind of inevitable. It's forking, and forking has certain problems.
tons of organisations write patches to open source projects and work with the community very well.
Yeah, but writing some patches for an OSS project is entirely different from taking a source tree and making a product out of it.
I agree it seems kinda frustrating, but I'm at a loss for what to do. You can't tell (or really even expect) Apple to jump through hoops to make it easy for the KDE folks. On the other hand, the KDE folks aren't being unreasonable in thinking that they should be able to merge Apple's work.
A major OS vendor dropped a new release, and this release is significant even among its peers (probably one of the more important updates to date).
If Longhorn came out tomorrow, there'd be a front page article about it and what MS was doing to promote it. If RedHat released a big new linux distro tomorrow, we'd have a front page article about it.
It's just the buzz combined with an otherwise slow news day.
It will radically change the way you think about coding. With lisp, you program at something akin to the parse-tree level. There is (almost) no syntax to Lisp except what you make.
It will show you to what higher order functions are canonically used for. Lisp heavily leverages anonymous functions as arguments to the core system calls. Languages with anonymous functions as first-class entities have remarkable properties that let you do amazing things with little effot.
It will teach you about a relatively uncommon variant technique of bottom-up programming, in which you define every problem with a domain-specific language. It is a very powerful technique.
Lisp has very, very powerful Object Oriented facilities. They are also very different from traditional OO features, so they should provide more perspective on the very difficult question, "What is Object Oriented Programming?" (If you think the answer to that question is easy, you need to learn Lisp).
Ajax is just using XMLHttpRequest to get object and using Javascript DOM to update the page accordingly.
There are various ways to accomplish this, depending on what toolkits you use to make your website. But certainly, an Ajax'd web application feels a lot smoother and more friendly than a non-Ajax'd application.
It's especially useful when editing lists, tables, or groups.
Or Microsoft could ensure that you do not need to run in Administrator mode in order to get things done.
Why do you need to run everyday operations as administrator? Why was this practice allowed to continue for so long? Microsoft was aware that this was bad practice before XP even launched. But they chose to do nothing about it.
So now MS says, "We could either continue to strangle our desktop users by further crippling them, or we can piss off serious network developers by forcing them to spend much more money on "Pro" products." They choose further stangulation, of course.
I'm glad that MS has decided that they know best what I should and should not do with my comptuer. Otherwise, who knows what manner of interesting things I might do.
Not only is the production quality really high, but apparently they also go retro in a few scenes so as to provide a tie in to Episode 4.
Evidently the action and dialog run much less awkwardly than in previous movies, and the plot is extremely dark. There is less comedy and more drama. They deal with some pretty heavy subject matter.
But let me reiterate. Kevin Smith is raving and drooling about this movie. My hopes have been suitably elevated. Now, I'm off to preorder a ticket.
They can't always work more closely with the original developer community for a variety of reasons. Most often in my experience, when an independant company decides to upgrade a open framework, they do it so fast that the volunteer-run developer community has difficulty reacting.
I think if you could solve this problem effectively there would be a lot of money in it for you. It's certainly not easy.
Slashdot Mirror
I don't disagree. Apple should support the full SAMBA spec.
But, please enable encrypted passwords. Not only will it get Tiger to interface with your server (small bonus) but it helps increase the security of your LAN. The last thing you'd want to do is give an attacker your password for free, with no effort at all. Then they wouldn't even have to hack your mac, they'd just use the password you graciously gave them.
This is for the good of the Internet. Get with it.
Ehh, Apple pushes for releases harder than KHTML does, because Apple has deadlines to meet for the larger product.
KHTML is an incredibly clean framework. It's hard not to look messy by comparison. It's not terribly fair though, WebCore is not a "messy" framework by any means.
Your "cookie" batch metaphor doesn't apply. First, it makes it seem like Apple is taking finite resources that other, more polite individuals perhaps, could use.
This is not the case.
Your metaphor also implies that somehow the KHTML is project is worse off for their involvement in Apple.
This is also not the case, unless you consider it from a PR standpoint, and then the point is arguable.
So pretty much, your entire post is -1 Wrong.
WebCore is not beautiful, but the KHTML team makes it sound like the software wasn't released, but instead clawed a bloody trail free from its unwilling host body and now assails innocent teens who are making out in the Old Lake House. It is not that bad at all. Certainly, it's above the standards of most software released today.
Perhaps you should, I dunno, catch up with the times. It's not about Ship Ship Ship, it's about keeping a sustainable release rate and measurable progress. Safari does what it needs to do, and it's not a horrible tangle of code (it is undeniably less clean that KHTML, I've worked with both and I admit WebCore could use some refactoring). That's part of commercial software. You're right that it's all got a subjective cost. I find anything relying Qt to be utterly corrupted. That's the point of this excercise, and part of my statement about your unreasonable expectations. Not only do I think that Apple didn't ever offically come out and say, "We're going to go hand-in-hand with the KHTML devs!" But I also submit that project focuses change over time. WebCore's current incarnation may not be something they envisioned when they began.Check out these points from "Principles of the Agile Manifesto":
- Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
- Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
- Continuous attention to technical excellence
and good design enhances agility.
- Simplicity--the art of maximizing the amount
of work not done--is essential.
Without question, software quality is important. But Agile developers accept that just "doing it right" is so difficult as to be impossible. Instead, we get the smallest slice of work that we can done, then refactor and iterate as needed.The between-the-lines point here is that getting working and not-awful code now is the secret to success in the long term. Dozens of projects have proven this over and over. UNIX is probably one of the most famous examples, as suggested in the famous "Worse Is Better" essay.
Polishing code until it's perfect without new feature development is an excellent way to get outdated.
People percieve this as arrogant on the KDE team's part because, simply put, Apple has a better rendering engine now. Part of the reasoning behind the lack of kickback is not just the absence of a CVS branch or lack of changelogs, but because the KHTML code is very "clean" and correct. The Apple code suffers from time-to-market-itis. So, the KHTML developers don't want to go through the effort of backporting.
Quite frankly, the KDE folks' mentality is out-of-style in the Agile Development world.
Wait, you're implying Apple comes in, does a smash and grab on freely available code, then instead of improving it (which they did), you imply that they slapped a MacOSX front on it, called it their own, then gave you the finger.That's wrong and you know it's wrong. If they did so little, why can't you backport the changes? Could it be, maybe, because they've made significant changes to the library, relying on their own APIs (just as KDE relies on KDE apis)?
Sounds to me like you had unreasonable expectations.
Apple is on record for offering to jointly attempt to make the important parts of WebCore cross-platform, similar to the situation with Gecko.
The KHTML team turned them down. They probably did so because it would shift the focus away from the KHTML they know and love and more towards the more realistic (but messier) WebCore, which they don't seem to want to do.
The KHTML team doesn't even seem to want many of the changes. Apple makes a product, and they don't care if they break small things to make deadlines. KHTML is a product of the opposite school, preferring to make a very small, clean codebase. The price of this is feature deficit.
This isn't about Apple being evil, or KHTML being snobs. It's about a project being forked. As time goes on, Apple has less and less to offer to KHTML. WebCore and KHTML are diverging, and people seem to be upset about this. I can't imagine why, this sort of separation was inevitable. Apple's best interests are served by leveraging their own excellent environment, and every time they do, they further exclude the KDE project.
Not at all. Even basic skills in programming give people tremendous advantages in modern society. While I agree that it'd be great to teach kinds more fundamental stuff like analytical skills, that's outside the scope of this discussion. I think we both agree that the education system needs to be reformed.
But, simply put, there are many opportunities that a programmer has in life that a non programmer doesn't even realize. The number of such opportunities goes up as the overall computer usage in society goes up. This is not like using a hammer. Most people do not use a hammer every day, because a hammer is a relatively specialized tool compared to a computer.
Part of the problem is how poorly american culture has adapted to the modern world of computing. Despite the fact that people use computers nearly every day in dozens of capacities, it's still considered an esoteric and specialist degree.
.com crash), or because they could get an associates degree at ITT (better than flipping burgers), or maybe they made some fast money making cheap ameturish webpages and now they think they can do anything (classic townie wannabe).
For example, look at how late in our educational system the process of programming education begins. Most "good" programmers I know were fooling around with code long before their schools ever even dreamed of introducing them to such concepts (usually around or before age 10, even!) Remember the Smalltalk project at PARC? They had children making animations, programs, games, and even simple applications. Obviously, children can understand it if you present it correctly.
Between this delay and the general American stigma against intellectualism, many of the programmers we produce are not terribly good at the job. Maybe they did it for the money (before the
What we need to do is teach kids to program at an earlier age. We also need to stop being so concerned about teaching them a "low" level language first. Let's start with Python or Ruby. Let's have them doing things instead of wasting time making for loops or calcualting array medians. Start making network-enabled applications, making interactive websites, etc.
Then, let's combine that with their math courses. As they learn math, they can learn the corresponding ways to do it on a computer (when feasible).
That way, they'll already know if they like programing or not, and they'll be able to make intelligent and informed decisions about what direction to steer their life. I can't tell you how many people I watched drop out of our CS Pre-major in college because they didn't realize what CS really was.
Also, why don't we see more vocational programs for cheap coding work? Not to offend web designers, but there's an example of a career that could be considered for vocational schools.
America is having problems keeping up with their demand because our entire society is shaped to ostracise young people who are interested in the subject, and discourage them. Only the most persistant and passionate people make it through, leading to a vast gulf between a "good" software engineer produced in America and a "bad" wage-slave class coder.
If by "already" you mean in less time than it too to emulate a completely different platform on the PSP, then maybe I'm impressed.
Every machine is hackable. The PSP seems especially so. That's what's making it stand out.
If Sony doesn't care, then why exactly did they allow PSPs to run applications off of memory sticks at all? Why does the PSP have so many extra little features?
I've talked about this before. I suspect that Sony wants to generate an underground development movement with the PSP to help draw people to it. Handheld platform competition is brutal, but the hackability of the PSP really makes it stand out compared to the DS (and previous consoles).
Sony will still make money with licensed games, the UMD format is closed (albeit hacked) and the physical media is difficult to reproduce. Their model is safe, while at the same time allowing for an underground community to exist.
Err, uhh, so what you're saying is that it's correct for Safari to prompt me before downloading it and running it from a click (that "has an application" prompt is in Safari), but when you put a special meta-refresh, it shouldn't?
Why?
It's not a serious issue, the damage caused is minimal, but these kinds of tiny holes have a way of being part of a larger attack.
The fix isn't anything so complex.
The fix is to make sure that Safari always prompts you before auto-install or safe open. Especially when it doesn't happen as the result of a GET (as in the example page, check out the refresh header at the top of the source, that's not cool).
I'm sure there are people out there who want reolving porn widgets on their dashboard. More power to them. What's key there is that they want and Safari needs to ensure that it always asks that question.
Thanks for the pointer. I actually do know about ATLAS and LAPACK. The reason I'm using the GSL is because of deployment ease. It's much harder to deploy fortran-based software than it is C-based software.
But it might be cool to distribute an ATLAS backend too.
It isn't a huge deal for most people, but it seems like the new GCC is singificantly better at optimizing for the PowerPC now.
I've been working with the GNU GSL on my mac a lot, and I recently updated to Tiger. The first thing I noticed when I recompiled the GSL with Apple's modified GCC4.0 is the significant and noticable speed increase. With this intense math stuff, doing SVD on 300x200 matricies, and it's shocking how much faster it is. I went from 3-5 seconds down to less than one.
I am not going to post any hard numbers because I haven't rigorously compared them yet, but I'll make some formal comparisons this week.
Another would be that Apple gets to work with their own libraries. This sucks for the KDE group, but it's kind of inevitable. It's forking, and forking has certain problems.
Yeah, but writing some patches for an OSS project is entirely different from taking a source tree and making a product out of it.
I agree it seems kinda frustrating, but I'm at a loss for what to do. You can't tell (or really even expect) Apple to jump through hoops to make it easy for the KDE folks. On the other hand, the KDE folks aren't being unreasonable in thinking that they should be able to merge Apple's work.
A major OS vendor dropped a new release, and this release is significant even among its peers (probably one of the more important updates to date).
If Longhorn came out tomorrow, there'd be a front page article about it and what MS was doing to promote it. If RedHat released a big new linux distro tomorrow, we'd have a front page article about it.
It's just the buzz combined with an otherwise slow news day.
- It will radically change the way you think about coding. With lisp, you program at something akin to the parse-tree level. There is (almost) no syntax to Lisp except what you make.
- It will show you to what higher order functions are canonically used for. Lisp heavily leverages anonymous functions as arguments to the core system calls. Languages with anonymous functions as first-class entities have remarkable properties that let you do amazing things with little effot.
- It will teach you about a relatively uncommon variant technique of bottom-up programming, in which you define every problem with a domain-specific language. It is a very powerful technique.
- Lisp has very, very powerful Object Oriented facilities. They are also very different from traditional OO features, so they should provide more perspective on the very difficult question, "What is Object Oriented Programming?" (If you think the answer to that question is easy, you need to learn Lisp).
Cheers.So, you came into a thread about a rave review for Star Wars Episode III. A review by Kevin Smith, Lifeling Star Wars Fanboi.
And you didn't expect a certain degree of fandom to emerge?
This just in, Kevin Smith fans are excited over his review of the new Star Wars movie. Grumpy Slashdotters are baffled.
Ajax is just using XMLHttpRequest to get object and using Javascript DOM to update the page accordingly.
There are various ways to accomplish this, depending on what toolkits you use to make your website. But certainly, an Ajax'd web application feels a lot smoother and more friendly than a non-Ajax'd application.
It's especially useful when editing lists, tables, or groups.
The fact that you're even saying this in response to a slashdot article posting means it's far too late.
Roll with it. It's not so bad a name.
KS said the movie was dark as in content. As in lots of violence and bad things happening.
Sheesh. Slashdotters.
Or Microsoft could ensure that you do not need to run in Administrator mode in order to get things done.
Why do you need to run everyday operations as administrator? Why was this practice allowed to continue for so long? Microsoft was aware that this was bad practice before XP even launched. But they chose to do nothing about it.
So now MS says, "We could either continue to strangle our desktop users by further crippling them, or we can piss off serious network developers by forcing them to spend much more money on "Pro" products." They choose further stangulation, of course.
I'm glad that MS has decided that they know best what I should and should not do with my comptuer. Otherwise, who knows what manner of interesting things I might do.
Kevin Smith liked it. He said he really liked it.
Not only is the production quality really high, but apparently they also go retro in a few scenes so as to provide a tie in to Episode 4.
Evidently the action and dialog run much less awkwardly than in previous movies, and the plot is extremely dark. There is less comedy and more drama. They deal with some pretty heavy subject matter.
But let me reiterate. Kevin Smith is raving and drooling about this movie. My hopes have been suitably elevated. Now, I'm off to preorder a ticket.
So what should Apple do then?
They can't always work more closely with the original developer community for a variety of reasons. Most often in my experience, when an independant company decides to upgrade a open framework, they do it so fast that the volunteer-run developer community has difficulty reacting.
I think if you could solve this problem effectively there would be a lot of money in it for you. It's certainly not easy.