You'll notice there are ton of packages listed above, and about 90% of them say "Avoid x! It's terrible!"
This is because ticketing systems are really easy in concept - user calls, take down issue, follow up with it - but very hard in practice. For instance, how do you handle taking down which user this issue affects? Drop-down box? (that's usually guess #1 for most packages). Bzzzzt. Try that with more than 50 users. Text field? Bzzzzzzzt. One day you'll have an incident for William Clinton, one day another incident for Bill Clinton, and you'll never correlate the two. We spent several revisions trying to figure out how to do just the name selection part correctly. And of course there are another 100 pitfalls after that one.
The problem is that this software is something that helpdesk techs sit in front of all day. And on-site techs have to interact with off-and-on all day. And if the software starts to get in anyone's way, there's nothing (aside from management decree) that can prevent people from just sending emails back and forth, instead. So you're basically competing with email, in terms of ease of use and people's comfort zones.
We spent a long time developing Max (plug, plug...), and it wasn't easy. Most packages suck, and are very expensive, and only get used because your boss tells you to. Ours, helpesk techs begged their bosses to use because they were afraid of being made to use the others (brag, brag).
Ultimately, if the software is too hard to use you won't use it. So I recommend keeping that requirement high in your list - higher than you might normally put it. It's especially hard for Slashdotters because we can pretty much use anything. Just because you can use a thing, doesn't mean you should. It's better to spend your time helping your users, not wrestling with crappy software.
I can say, I work on a helpdesk supporting around 1000 users or so. And the majority of our Knowledge Base articles we have are on how to handle various bizarre and weird things that go on in Notes. And a big chunk of calls, disproportionately large, are about Notes.
I support Notes, and I hate Notes. My co-workers hate Notes, and my users hate Notes. I don't know anything about the Server side, but I would not inflict Notes on anyone willingly ever. It's shit.
As to why - yes, everyone else has explained that it's due to Notes being a full-fledged database replication system. Which is nice. But sometimes people just want an email client.
Re:Why use XHTML when IE cannot parse it?
on
The Future of HTML
·
· Score: 1
The Phrase "Considered Harmful" Should be Considered Harmful -
In short, I believe, Hixie's use of plain text, that ancient phrase, and other cues tries (avoiding the first person, reading like a standards document) to lend more weight to his statements than they deserve. Even I fell victim to it. But I believe he's wrong.
Unfortunately, I didn't say it very well. Well, too bad, at least I said it.
Most - if not all - internet connections are nowadays behind a NAT connection, which is a de-facto firewall. Those firewalls tend to take advantage of UDP and TCP connections having port numbers, and renumbering the ports. What if we were to somehow merge the IP addresses, and the TCP/UDP Port Numbers together into a 32(IP part)+16(port number)+1(UDP-vs.TCP) address? That would give us a 49 bit address space - which would be far more comfortable. No re-coding applications (for the most part) - the same basic IPv4 calls would work. But instead of allocating an entire IPv4 addresses to a machine, you would allocate instead an IP and a port number to a machine. This could be nicely backwards compatible with firewalls that are out there, and everything. And probably wouldn't change how the Internet is routed.
You'd still have problems with Well Known Services tending to reside on certain ports, but you could help reduce that by adding some stuff to DNS to return port numbers as well as IP addresses.
And I can say, for sure, that Sybase is a damned good DB. I originally wrote my application to run on Postgres, and I ran into crushing performance problems on a torture test that I concocted - one 'simple' query ran for a few minutes.
Since I was having performance problems, I figured I'd try to move over to MySQL. It was hard, but I managed, and it ran fine. Very fast.
Finally, I decided I needed to use a 'Commercial' database. After evaluating costs and everything else, I went with Sybase, version 11.0.3, which was (and is, if you can find it) free to develop on and even deploy software based on it. It's run solidly since. Never a hiccup. Then again, I never had any reliability or crashing problems with Postgres or MySQL, so that's not as telling. But what is telling is that it's _fast_.
Now that they've come out with this new version, I think I may upgrade to it - I don't think my data is larger than 5 GB anyways, nor do I intend to use more than 1 CPU. But until now I figured I was just going to have to wait until I could afford the pay version, or move again to something else.
I'm figuring their real hope is for people to try this one out, develop on it, and when they outgrow it, buy the pay version. Which sounds pretty reasonable to me.
IP v6 is not a particularly good solution. The address fields are way too wide - and when you try to layer TCP on there, the per-packet overhead is just too big.
That, plus it doesn't seem to be backwards-compatible enough. I think a solution could be engineered whereby hosts that are really on the internet (not behind a firewall) switch to whatever new scheme is supposed to be in use, and regular client machines continue to operate behind NAT's, etc. You could unify the TCP port number and the IPv4 address into some IPv7 (or whatever) unique destination/service identifier.
Considering that there are almost no uses for IP without TCP (or UDP), not unifying those two protocols is just wasteful.
There seem to be more and more client technologies that we're supposed to be able to use to make our web application lifestyle better -
Flash
Java
DHTML
And there are a ton of languages which are supposed to make our lives better, too -
Java
Perl
PHP
Whatever.NET
And of course we're supposed to run these wonderful things -
On our own, secure, happy, well-administered server, behind our firewall
On a service providers managed, well-maintained, backed-up server, in some co-lo facility somewhere
And when we do manage to get all of these crazy things to try to talk to eachother, somehow, we can choose among 5,000,000 different XML languages/schemas/whatevers to use.
Web-based computing is still in the stone age - if I can ever manage to get my own stupid project off the ground, perhaps I'll have a solution for this, soon enough...
I store all my emails, contacts, URL's, and some files on some webserver software that I wrote called Appslink. It uses a non-hierarchical filesystem by default - (e.g, my Slashdot URL lives in both the "Daily Websites" category and the "Geek Stuff" category.)
It's a pain in the ass to use, sometimes, and the UI makes a lot of my friends want to puke, but I'm working on it... And hey, I haven't lost a piece of email in years. All 12 thousand or so, stored on a nice big database. Of course, whenever someone says, "Hey, check your email" and I have to say, "Well, uh, I have to wait 5 minutes, cuz I don't have a 'check now' button..." I get a lot of exasperated sighs from people. But oh well.
In regards to all of the 'X is obsolete' arguing -
There was a design decision made when creating X that displaying windows on a local workstation should be as easy as displaying windows on a remote workstation. This decision affected several things about X, and made the X API's extremely difficult to learn (pick up an X book, you'll see), but extremely powerful.
Basically, what some people are saying is that that decision was wrong - that it's not correct to design an entire graphics API around the concept of displaying windows locally and remotely.
Really, the most objective way to analyze that claim is to look at how many windows users open on their own workstation, versus how many remoted X applications they run. Compare that percentage. Then take a look at how much more complex X was made to handle the eventuality of having to handle remote windows, etc, etc. Is it worth it?
Me personally, I don't think so. The only real use I've had for remote X applications was in terms of systems administration - but this is stuff I could have done as easily with something like ssh, or, if I needed some kind of graphics, PC Anywhere, or Timbuktu. And for applications to be faster, better behaved, and less bloatey, I'd be willing to install some PC anywhere-style application on the occasional remotely-controlled server. For the most part, people would be able to leave it out.
That being said, I've never used X in a thin-client environment - it's possible that it could perform quite well - and I've heard that the X protocols are very good at keeping network use down. It still strikes me as not the right distribution of power between server and client, but what the hell do I know?
This should be an interesting article - hey, new version of xyz is out, now it does feature blah. Great news.
But instead, there's stupid recurring garbage with idiots on both sides trying to explain that one database is better than another. Here's what I think the objective truth is - the fact of the matter is whatever works for you is fine.
If you like using stored procedures, triggers and constraints and think SQL compliance is important, then use Postgresql, and it will work fine for you. If you don't, and you like fast access to your data, use MySQL.
There are use scenarios that one can construct which will make either database look completely ridiculous and terrible (look at some of the comments for some examples). But it doesn't matter, if you can code for MySQL and think in MySQL, it will work fine. If you code for Postgresql and think in Postgresql, it will work fine. I've used both, in heavy and light production environments, and they both have their uses. I've also found scenarios where I can't use either, and have to go to something else.
To all those who say, "But...but...MySQL is just a fake SQL interface to the filesystem!" Well, fine. Where do you store your files, then? I presume, since a filesystem is such a terrible place to put your files, that it's not in a filesystem, eh?
And to those who say, "but, I can SELECT out of MySQL eight hundred bajillion times faster than Postgresql!" Well, fine, but what happens if you try to concurrently insert something? How's your data integrity hold up if some errant SQL inserts data that doesn't refer properly to other tables?
What I'm trying to say is that it's all relative, and trying to phrase things as, "This is the right thing to do, in all cases, for all scenarios" is narrow-minded and simplistic. Use what works for you - and note that a lot of this depends on how you think when you are writing your code. So two different programmers working on the same problem might solve the problem using different databases - and both be right.
That makes sense, in the desktop space. That you can outperform an Alpha with an x86, I get.
However, there are times when you need to address more than 4GB of memory space. And in that regard, isn't the Alpha damned viable - or shouldn't it be?
It's easier to download the source and just read that than it is to read the comments and documentation about this project. I just did. My take is that it's more of an XML application, not really any kind of fundamental change to XML, PHP, or MySQL. It seems to be a set of table definitions and some PHP stuff to take in XML, throw it in the MySQL DB.
It doesn't seem to take advantage of any of the high-speed MySQL features - this could work with any DB, I'd bet.
I've noticed a lot of comments stating "this is useless, because the browsers won't render it."
That's true - the current browsers won't render it. And they can barely render various other simple features, blah blah blah. However, this sets the stage for several years from now - when browsers will render it. I'd figure four years.
For example, just now, it's becoming possible to design web pages with CSS and relatively plain HTML markup. CSS having been established in late 1996, according to this. So, figure four or five years from now we may start designing web pages in XHTML 2.0, and Dreamweaver version 53 or whatever might actually spit out pages in XHTML 1.0.
I know it's annoying that progress is so slow, but that's how it goes.
If you have actual physical real software running on your local machine that your web browser can call out to (e.g, via MIME-type to program association), then yes, you're absolutely right.
But that's not what I'm talking about, here. How do you get one server-based app (which is viewed through a web-browser) to take advantage of some other server-based app (not on the same server - hell, not even hosted from the same place)? The important trick to note here is - without using any client software? How do you do it?
Probably the biggest complaint that one could have against web services is the difficulty involved in getting separate ones to interoperate.
Imagine you have a web-based e-mail system. And a web-based word-document reader. One written in J2EE and one written in.NET. Click on a word attachment in the e-mail program, any guess as to whether or not it will open in your word-document reader? Answer is nope!
That people are just now figuring out that demanding that all things be written in One True Language to be hosted on One True Platform from One Designated Service Provider is kinda sad - doesn't that sound restrictive?
Of course, my commentary on this issue isn't coming from nowhere - I wrote a service designed to fix the problem, at its core. But just because I'm biased doesn't mean I'm wrong.
RedHat up2date is great, why no mention of it?!
on
Is RPM Doomed?
·
· Score: 1
There are two issues here - one is package formats, and one is centralized update databases/repositories. RPM is a package management format, and up2date is the centralized repository. For RedHat, at least.
I admin RedHat servers, development workstations, etc.
If you set it up properly, you can run "up2date -u" and it will automatically update all of your RPM's. No one seems to have mentioned this... I guess because the tinfoil-hat brigade doesn't like "registering" with redhat (via rhn_register, necessary to make up2date work).
I can also go to https://rhn.redhat.com, login, and schedule my machine to automatically download the latest revision to some RPM. It's free if you only do it on one box.
I've had zero dependency problems since I became an up2date fan. It really should be mentioned with the above article.
#1) I don't care what license software development (government or otherwise) is done in. GPL, BSD, or closed-source. If some piece of software leads towards somewhere interesting, and the license is unusable for your purposes, then re-write the software. A guy named Linus did this, once.
#2) How many companies start from government-funded research? How many do not? Whatever the percentage, I'm banking that it's not 100%. This is not the 'thin edge of the wedge/slippery slope' opening salvo that some are making it out to be. Were Gates' comments to be immediately implemented (which I doubt), I don't imagine the impact would be too terribly heavy.
Gates is just saying something that will benefit his company, and harm his enemies. What else is new?
I can imagine the conversations I'd have with my friends -
Dude, we've gotta pick this one up! It says here: "Surgeon General's Warning - this game can be highly addictive to susceptible persons - excercise caution and restraint in purchase and use. Sony(tm) assumes no liability for damage to work, friendships, relationships or sex lives due to excessive play of this game." Awesome! Let's get it!
It'd become marketing - video game makers wouldn't bother to release games without the sticker.
And of course, this is the same kind of legal action that makes it so that a cup of coffee now has a warning on it - 'Warning - this beverage is extremely hot'.
What you're asking for, in essence, is exactly what I've been working on for almost two years now. It's not ready yet - it's not even ready for developer's use yet, but it's getting there.
Here's the faq - I think it's generally what you're looking for. The developer's documentation (for developers who want to make software that works with the OS) is terribly out of date. So I'm not posting it.
I've always wanted to post this to the slashdot folks, but I had intended to wait until I at least had the developer release out - unfortunately, this article posed exactly the question that I've been trying to answer...So here I am vapor-ing my own product. Sigh.
I'm no SOAP apologist, nor am I any kind of neo-luddite anti-XML bigot, but this article is weak, at best.
The article states (I'm paraphrasing)-
SOAP is complex - yes it is. It is also powerful. Oftentimes, that's how things work out. Sometimes, when you're really lucky, simple will be powerful.
SOAP can go through firewalls - yes, it can also not. So what?
MS visual studio makes it too easy to make SOAP-speaking services. - first - there's nothing wrong with that. Second, that has nothing to do with SOAP, the protocol.
SOAP encourages developers to design their own protocols to transport SOAP data around - this is a terrible straw-man argument. I don't see where this is coming from.
The web has a unified namespace, SOAP does not - this is true. Probably the least invalid of the author's claims. But the 'X does something new, and does so in a new fashion, therefore X is less secure' taken to extreme would imply no new protocols would ever be created. I'm not saying that the author is saying nothing new should ever be created, but I am noting that his argument, to the extreme, would completely retard progress.
SOAP security literature is misleading, security rests with the developer - any specification for how to interchange data, and make actual changes to state, places an implicit burden of security on the developer of services of said protocol. SOAP is no exception. Neither is HTTP, or XML-RPC, or sending Comma-seperated values via FTP or carrier pigeon. The problem is not specific to SOAP.
SOAP is new and untested - another valid point. It is. It may become something very powerful and useful, in the future.
All that being said - I think that SOAP is overkill, does not address real legitimate needs at this time, and isn't going to become the panacea that many predict. But this article doesn't effectively attack SOAP's weaknesses, by focusing on the security problems 'inherent' in SOAP. Those security problems are the same for anything developed on top of, or as an extension to, HTTP. SOAP's weaknesses are its complexity, and that a subset of SOAP (say, a third of it) can solve 99% of the problems that SOAP purports to solve. I just had problems with some poorly-executed attacks on SOAP as a protocol. End Rant.
HTTP is the best, thus far...put a layer on top
on
HTTP's Days Numbered
·
· Score: 2, Interesting
I am familiar with a lot of protocols, and I've got to say, HTTP is my favorite. It's dirt simple, it's extensible, it's fast, it's 8-bit-clean, it's stateless.
The great thing about HTTP to me is all the stuff that was left out. And if you really want that stuff, there's WebDAV, which also seems to be a decent protocol - but I'd have to look into it more to get a better idea.
For those people who don't like a gajillion different services running on port 80, then don't run them on port 80! You could have a user-facing webserver responding to port 80, and an XML-RPC server responding on port 8080, and a SOAP server on 8081 - there you go, problem solved.
The real problem presented by this article - of long-running transactions - definitely is outside of the scope of HTTP. But the best solution to this might be another protocol on top of HTTP. I imagine something that initiates some transaction with a transaction-id, then closes the connection, and waits (possibly days) for a connection to come back with that same transaction-id. Voila. Problem solved. Of course there'd be more to it than that, but that's the basic idea.
Am I talking out of my ass? I sure am! And I assume you are, too, since we don't have the actual programmer's guide for the CPU. So bear with me a minute.
If the processor could handle two completely separate processes, it would be just a dual-core CPU, right? And if it were, it wouldn't be called 'SMT' - it would be called a multi-core CPU. Furthermore, this technique of SMT is designed to work around 'small' problems like pipeline stalls - that's not something you're going to solve by doing a full task-switch within the CPU - task switches take a long time. Switching from one thread to another that lives in the same process-space seems more like what they would be trying to do. So from that, I would figure that SMT only works with two threads with the same address space.
We know that the CPU needs some OS extensions in order to run - that's mentioned in the article. Those extensions would be for, I presume, scheduling. In other words, code that says: "when one thread/process is running, schedule another to run also if it lives in the same memory space. But if you've got two separate runable processes hanging out, only have one actively running."
All that I'm saying is conjecture, sure, and in some other dicussions on this topic people who actually know what they're talking about are probably saying far more interesting things than this.
Crap - just finished the article where they said that it doesn't really help that much.
Whoops! Well, I'll stick with the '..later steppings' line - when they start slapping a couple more ALU's and other processing units on the CPU so that more 'stuff' is available for the second thread, then it could be good!
Until then, I guess it's kinda like the Itanium - good as an experiment to see what things can be like in the near future, but not as useful for day-to-day operations.
Oh well - wish I could just edit my comment above!
For tasks that can be easily split into two threads, I have a feeling that hyperthreading could be better than two processors. But, since threading seems to be better implemented on Windows, NT boxen might enjoy the benefits more.
The best example of how to split a task into threads (that I like to use) is rendering a 3D image to screen. If you want to split that task so that two threads (and thus two processors) can work on it, you just make one thread handle 'even' scan lines and one thread handle 'odd' lines. Keeping the caches cohereent between the two CPU's can be difficult - they're both executing the same code, and might also be twiddling around some piece of memory that they share.
My point is, with this hyperthreading business, that there's only one cache - so no more cache coherency bothers. I might be concerned that the arithemetic units or whatever else that are on the chip might be in contention for use - but they can just add more of 'em in later steppings of the CPU.
The problem for us Unix-lovin' folk is that Unix-esque OS'es don't often take threading very seriously. OpenBSD, for example, doesn't even have a kernel-threading implementation (correct me if I am wrong!) The 'Unix Way' is to just fork a process and run two process images. That's fifty billion times easier to debug than two threads that step on eachothers' data (see deadlock). But the forking method - even with nifty things like copy-on-write process images and such - doesn't seem to use as little memory, or perform as quickly, or process-switch as fast.
When I speak to developers who know their stuff (more than I do) they say - on NT, make a whole bunch of threads and make them talk to eachother with semaphores and stuff - on Unix, fork and write to a pipe. Nothing fundamentally wrong with that division, but advances such as this Hyperthreading thing won't work as well on Linux, I don't think.
Slashdot Mirror
You'll notice there are ton of packages listed above, and about 90% of them say "Avoid x! It's terrible!"
This is because ticketing systems are really easy in concept - user calls, take down issue, follow up with it - but very hard in practice. For instance, how do you handle taking down which user this issue affects? Drop-down box? (that's usually guess #1 for most packages). Bzzzzt. Try that with more than 50 users. Text field? Bzzzzzzzt. One day you'll have an incident for William Clinton, one day another incident for Bill Clinton, and you'll never correlate the two. We spent several revisions trying to figure out how to do just the name selection part correctly. And of course there are another 100 pitfalls after that one.
The problem is that this software is something that helpdesk techs sit in front of all day. And on-site techs have to interact with off-and-on all day. And if the software starts to get in anyone's way, there's nothing (aside from management decree) that can prevent people from just sending emails back and forth, instead. So you're basically competing with email, in terms of ease of use and people's comfort zones.
We spent a long time developing Max (plug, plug...), and it wasn't easy. Most packages suck, and are very expensive, and only get used because your boss tells you to. Ours, helpesk techs begged their bosses to use because they were afraid of being made to use the others (brag, brag).
Ultimately, if the software is too hard to use you won't use it. So I recommend keeping that requirement high in your list - higher than you might normally put it. It's especially hard for Slashdotters because we can pretty much use anything. Just because you can use a thing, doesn't mean you should. It's better to spend your time helping your users, not wrestling with crappy software.
I can say, I work on a helpdesk supporting around 1000 users or so. And the majority of our Knowledge Base articles we have are on how to handle various bizarre and weird things that go on in Notes. And a big chunk of calls, disproportionately large, are about Notes.
I support Notes, and I hate Notes. My co-workers hate Notes, and my users hate Notes. I don't know anything about the Server side, but I would not inflict Notes on anyone willingly ever. It's shit.
As to why - yes, everyone else has explained that it's due to Notes being a full-fledged database replication system. Which is nice. But sometimes people just want an email client.
I wrote about that famous page in my blog -
- html-401.html
http://uberbrady.blogspot.com/2005/09/xhtml-10-vs
I really should have called my blog entry -
The Phrase "Considered Harmful" Should be Considered Harmful -
In short, I believe, Hixie's use of plain text, that ancient phrase, and other cues tries (avoiding the first person, reading like a standards document) to lend more weight to his statements than they deserve. Even I fell victim to it. But I believe he's wrong.
Unfortunately, I didn't say it very well. Well, too bad, at least I said it.
Most - if not all - internet connections are nowadays behind a NAT connection, which is a de-facto firewall. Those firewalls tend to take advantage of UDP and TCP connections having port numbers, and renumbering the ports. What if we were to somehow merge the IP addresses, and the TCP/UDP Port Numbers together into a 32(IP part)+16(port number)+1(UDP-vs.TCP) address? That would give us a 49 bit address space - which would be far more comfortable. No re-coding applications (for the most part) - the same basic IPv4 calls would work. But instead of allocating an entire IPv4 addresses to a machine, you would allocate instead an IP and a port number to a machine. This could be nicely backwards compatible with firewalls that are out there, and everything. And probably wouldn't change how the Internet is routed. You'd still have problems with Well Known Services tending to reside on certain ports, but you could help reduce that by adding some stuff to DNS to return port numbers as well as IP addresses.
And I can say, for sure, that Sybase is a damned good DB. I originally wrote my application to run on Postgres, and I ran into crushing performance problems on a torture test that I concocted - one 'simple' query ran for a few minutes.
Since I was having performance problems, I figured I'd try to move over to MySQL. It was hard, but I managed, and it ran fine. Very fast.
Finally, I decided I needed to use a 'Commercial' database. After evaluating costs and everything else, I went with Sybase, version 11.0.3, which was (and is, if you can find it) free to develop on and even deploy software based on it. It's run solidly since. Never a hiccup. Then again, I never had any reliability or crashing problems with Postgres or MySQL, so that's not as telling. But what is telling is that it's _fast_.
Now that they've come out with this new version, I think I may upgrade to it - I don't think my data is larger than 5 GB anyways, nor do I intend to use more than 1 CPU. But until now I figured I was just going to have to wait until I could afford the pay version, or move again to something else.
I'm figuring their real hope is for people to try this one out, develop on it, and when they outgrow it, buy the pay version. Which sounds pretty reasonable to me.
IP v6 is not a particularly good solution. The address fields are way too wide - and when you try to layer TCP on there, the per-packet overhead is just too big.
That, plus it doesn't seem to be backwards-compatible enough. I think a solution could be engineered whereby hosts that are really on the internet (not behind a firewall) switch to whatever new scheme is supposed to be in use, and regular client machines continue to operate behind NAT's, etc. You could unify the TCP port number and the IPv4 address into some IPv7 (or whatever) unique destination/service identifier.
Considering that there are almost no uses for IP without TCP (or UDP), not unifying those two protocols is just wasteful.
- Flash
- Java
- DHTML
And there are a ton of languages which are supposed to make our lives better, too -- Java
- Perl
- PHP
- Whatever.NET
And of course we're supposed to run these wonderful things -And when we do manage to get all of these crazy things to try to talk to eachother, somehow, we can choose among 5,000,000 different XML languages/schemas/whatevers to use.
Web-based computing is still in the stone age - if I can ever manage to get my own stupid project off the ground, perhaps I'll have a solution for this, soon enough...
It's a pain in the ass to use, sometimes, and the UI makes a lot of my friends want to puke, but I'm working on it... And hey, I haven't lost a piece of email in years. All 12 thousand or so, stored on a nice big database. Of course, whenever someone says, "Hey, check your email" and I have to say, "Well, uh, I have to wait 5 minutes, cuz I don't have a 'check now' button..." I get a lot of exasperated sighs from people. But oh well.
There was a design decision made when creating X that displaying windows on a local workstation should be as easy as displaying windows on a remote workstation. This decision affected several things about X, and made the X API's extremely difficult to learn (pick up an X book, you'll see), but extremely powerful.
Basically, what some people are saying is that that decision was wrong - that it's not correct to design an entire graphics API around the concept of displaying windows locally and remotely.
Really, the most objective way to analyze that claim is to look at how many windows users open on their own workstation, versus how many remoted X applications they run. Compare that percentage. Then take a look at how much more complex X was made to handle the eventuality of having to handle remote windows, etc, etc. Is it worth it?
Me personally, I don't think so. The only real use I've had for remote X applications was in terms of systems administration - but this is stuff I could have done as easily with something like ssh, or, if I needed some kind of graphics, PC Anywhere, or Timbuktu. And for applications to be faster, better behaved, and less bloatey, I'd be willing to install some PC anywhere-style application on the occasional remotely-controlled server. For the most part, people would be able to leave it out.
That being said, I've never used X in a thin-client environment - it's possible that it could perform quite well - and I've heard that the X protocols are very good at keeping network use down. It still strikes me as not the right distribution of power between server and client, but what the hell do I know?
But instead, there's stupid recurring garbage with idiots on both sides trying to explain that one database is better than another. Here's what I think the objective truth is - the fact of the matter is whatever works for you is fine.
If you like using stored procedures, triggers and constraints and think SQL compliance is important, then use Postgresql, and it will work fine for you. If you don't, and you like fast access to your data, use MySQL.
There are use scenarios that one can construct which will make either database look completely ridiculous and terrible (look at some of the comments for some examples). But it doesn't matter, if you can code for MySQL and think in MySQL, it will work fine. If you code for Postgresql and think in Postgresql, it will work fine. I've used both, in heavy and light production environments, and they both have their uses. I've also found scenarios where I can't use either, and have to go to something else.
To all those who say, "But...but...MySQL is just a fake SQL interface to the filesystem!" Well, fine. Where do you store your files, then? I presume, since a filesystem is such a terrible place to put your files, that it's not in a filesystem, eh?
And to those who say, "but, I can SELECT out of MySQL eight hundred bajillion times faster than Postgresql!" Well, fine, but what happens if you try to concurrently insert something? How's your data integrity hold up if some errant SQL inserts data that doesn't refer properly to other tables?
What I'm trying to say is that it's all relative, and trying to phrase things as, "This is the right thing to do, in all cases, for all scenarios" is narrow-minded and simplistic. Use what works for you - and note that a lot of this depends on how you think when you are writing your code. So two different programmers working on the same problem might solve the problem using different databases - and both be right.
However, there are times when you need to address more than 4GB of memory space. And in that regard, isn't the Alpha damned viable - or shouldn't it be?
I presume Digital...Compaq...whoever.. killed it for purely political reasons? Or are there some technical reasons I don't get?
It doesn't seem to take advantage of any of the high-speed MySQL features - this could work with any DB, I'd bet.
That's true - the current browsers won't render it. And they can barely render various other simple features, blah blah blah. However, this sets the stage for several years from now - when browsers will render it. I'd figure four years.
For example, just now, it's becoming possible to design web pages with CSS and relatively plain HTML markup. CSS having been established in late 1996, according to this. So, figure four or five years from now we may start designing web pages in XHTML 2.0, and Dreamweaver version 53 or whatever might actually spit out pages in XHTML 1.0.
I know it's annoying that progress is so slow, but that's how it goes.
But that's not what I'm talking about, here. How do you get one server-based app (which is viewed through a web-browser) to take advantage of some other server-based app (not on the same server - hell, not even hosted from the same place)? The important trick to note here is - without using any client software? How do you do it?
That is what my stuff purports to solve.
Imagine you have a web-based e-mail system. And a web-based word-document reader. One written in J2EE and one written in .NET. Click on a word attachment in the e-mail program, any guess as to whether or not it will open in your word-document reader? Answer is nope!
That people are just now figuring out that demanding that all things be written in One True Language to be hosted on One True Platform from One Designated Service Provider is kinda sad - doesn't that sound restrictive?
Of course, my commentary on this issue isn't coming from nowhere - I wrote a service designed to fix the problem, at its core. But just because I'm biased doesn't mean I'm wrong.
I admin RedHat servers, development workstations, etc. If you set it up properly, you can run "up2date -u" and it will automatically update all of your RPM's. No one seems to have mentioned this... I guess because the tinfoil-hat brigade doesn't like "registering" with redhat (via rhn_register, necessary to make up2date work).
I can also go to https://rhn.redhat.com, login, and schedule my machine to automatically download the latest revision to some RPM. It's free if you only do it on one box.
I've had zero dependency problems since I became an up2date fan. It really should be mentioned with the above article.
#1) I don't care what license software development (government or otherwise) is done in. GPL, BSD, or closed-source. If some piece of software leads towards somewhere interesting, and the license is unusable for your purposes, then re-write the software. A guy named Linus did this, once.
#2) How many companies start from government-funded research? How many do not? Whatever the percentage, I'm banking that it's not 100%. This is not the 'thin edge of the wedge/slippery slope' opening salvo that some are making it out to be. Were Gates' comments to be immediately implemented (which I doubt), I don't imagine the impact would be too terribly heavy.
Gates is just saying something that will benefit his company, and harm his enemies. What else is new?
It'd become marketing - video game makers wouldn't bother to release games without the sticker.
And of course, this is the same kind of legal action that makes it so that a cup of coffee now has a warning on it - 'Warning - this beverage is extremely hot'.
Here's the faq - I think it's generally what you're looking for. The developer's documentation (for developers who want to make software that works with the OS) is terribly out of date. So I'm not posting it.
I've always wanted to post this to the slashdot folks, but I had intended to wait until I at least had the developer release out - unfortunately, this article posed exactly the question that I've been trying to answer...So here I am vapor-ing my own product. Sigh.
The article states (I'm paraphrasing)-
SOAP is complex - yes it is. It is also powerful. Oftentimes, that's how things work out. Sometimes, when you're really lucky, simple will be powerful.
SOAP can go through firewalls - yes, it can also not. So what?
MS visual studio makes it too easy to make SOAP-speaking services. - first - there's nothing wrong with that. Second, that has nothing to do with SOAP, the protocol.
SOAP encourages developers to design their own protocols to transport SOAP data around - this is a terrible straw-man argument. I don't see where this is coming from.
The web has a unified namespace, SOAP does not - this is true. Probably the least invalid of the author's claims. But the 'X does something new, and does so in a new fashion, therefore X is less secure' taken to extreme would imply no new protocols would ever be created. I'm not saying that the author is saying nothing new should ever be created, but I am noting that his argument, to the extreme, would completely retard progress.
SOAP security literature is misleading, security rests with the developer - any specification for how to interchange data, and make actual changes to state, places an implicit burden of security on the developer of services of said protocol. SOAP is no exception. Neither is HTTP, or XML-RPC, or sending Comma-seperated values via FTP or carrier pigeon. The problem is not specific to SOAP.
SOAP is new and untested - another valid point. It is. It may become something very powerful and useful, in the future.
All that being said - I think that SOAP is overkill, does not address real legitimate needs at this time, and isn't going to become the panacea that many predict. But this article doesn't effectively attack SOAP's weaknesses, by focusing on the security problems 'inherent' in SOAP. Those security problems are the same for anything developed on top of, or as an extension to, HTTP. SOAP's weaknesses are its complexity, and that a subset of SOAP (say, a third of it) can solve 99% of the problems that SOAP purports to solve. I just had problems with some poorly-executed attacks on SOAP as a protocol. End Rant.
The great thing about HTTP to me is all the stuff that was left out. And if you really want that stuff, there's WebDAV, which also seems to be a decent protocol - but I'd have to look into it more to get a better idea.
For those people who don't like a gajillion different services running on port 80, then don't run them on port 80! You could have a user-facing webserver responding to port 80, and an XML-RPC server responding on port 8080, and a SOAP server on 8081 - there you go, problem solved.
The real problem presented by this article - of long-running transactions - definitely is outside of the scope of HTTP. But the best solution to this might be another protocol on top of HTTP. I imagine something that initiates some transaction with a transaction-id, then closes the connection, and waits (possibly days) for a connection to come back with that same transaction-id. Voila. Problem solved. Of course there'd be more to it than that, but that's the basic idea.
If the processor could handle two completely separate processes, it would be just a dual-core CPU, right? And if it were, it wouldn't be called 'SMT' - it would be called a multi-core CPU. Furthermore, this technique of SMT is designed to work around 'small' problems like pipeline stalls - that's not something you're going to solve by doing a full task-switch within the CPU - task switches take a long time. Switching from one thread to another that lives in the same process-space seems more like what they would be trying to do. So from that, I would figure that SMT only works with two threads with the same address space.
We know that the CPU needs some OS extensions in order to run - that's mentioned in the article. Those extensions would be for, I presume, scheduling. In other words, code that says: "when one thread/process is running, schedule another to run also if it lives in the same memory space. But if you've got two separate runable processes hanging out, only have one actively running."
All that I'm saying is conjecture, sure, and in some other dicussions on this topic people who actually know what they're talking about are probably saying far more interesting things than this.
Whoops! Well, I'll stick with the '..later steppings' line - when they start slapping a couple more ALU's and other processing units on the CPU so that more 'stuff' is available for the second thread, then it could be good!
Until then, I guess it's kinda like the Itanium - good as an experiment to see what things can be like in the near future, but not as useful for day-to-day operations.
Oh well - wish I could just edit my comment above!
The best example of how to split a task into threads (that I like to use) is rendering a 3D image to screen. If you want to split that task so that two threads (and thus two processors) can work on it, you just make one thread handle 'even' scan lines and one thread handle 'odd' lines. Keeping the caches cohereent between the two CPU's can be difficult - they're both executing the same code, and might also be twiddling around some piece of memory that they share.
My point is, with this hyperthreading business, that there's only one cache - so no more cache coherency bothers. I might be concerned that the arithemetic units or whatever else that are on the chip might be in contention for use - but they can just add more of 'em in later steppings of the CPU.
The problem for us Unix-lovin' folk is that Unix-esque OS'es don't often take threading very seriously. OpenBSD, for example, doesn't even have a kernel-threading implementation (correct me if I am wrong!) The 'Unix Way' is to just fork a process and run two process images. That's fifty billion times easier to debug than two threads that step on eachothers' data (see deadlock). But the forking method - even with nifty things like copy-on-write process images and such - doesn't seem to use as little memory, or perform as quickly, or process-switch as fast.
When I speak to developers who know their stuff (more than I do) they say - on NT, make a whole bunch of threads and make them talk to eachother with semaphores and stuff - on Unix, fork and write to a pipe. Nothing fundamentally wrong with that division, but advances such as this Hyperthreading thing won't work as well on Linux, I don't think.