. ..under Linux, where the threads implementation isn't exactly stellar.
I thought it was more the case that processes under Linux are stellar in comparison to proprietary OS's - so, under Linux, thread-based progs really aren't any faster that process-based ones. (whereas on an OS like NT, a process-based app is useless, so everything has to be multithreaded)
The "Real World" uses stored procedures and transactions
Transactions, yes.
Stored procedures - sometimes yes, sometimes no. There are advantages (increased speed) and disadvantages (decreased flexibility, portability) to using stored procedures. Some shops always use them, some never use them, and the rest mix & match as they see fit. Point being, there definitely are "Real World", well-written db systems that don't heavily use stored procedures.
I've seen a plain old nmap scan send a stock solaris box into a syslogging frenzy, ending only when the/var partition filled up and the sysadmin noticed that there were some disk-space issues.
Having read the current posts to this thread, I'm getting the impression that VA has a bit of improvement to do with their support system.
How about Penguin Computing? They seem to offer the equivalent in the rackmount dept., and have similar pricing. What experiences have people had with their stuff?
Compared to what? I've been pricing some SMP rackmount machines for my company, comparing VA Linux, Penguin Computing, Dell, and Compaq, and the first two are significantly cheaper than the second two.
Since we're talking about production systems, I don't think saving a few bucks by rolling our own would be a great idea, even though I do it for my personal machines. When a server pukes a 1 am I'd rather have some company I can complain to, than go second-guess my assembly work.
WAP hasn't increased the problems at all because it uses WML not HTML.
Maybe in theory... in reality, every WAP phone in the US comes with the phone.com browser, which lies like a dog in its accept header - for example, all the browsers claim to accept text/html, when in fact some of them do not. So, if you're developing web apps that need to work with multiple WAP phones, you need to get your hands dirty by sniffing the user-agent, instead of just looking at the accept header. Stupid stupid stupid.
For comparison purposes, what checkpoint has to its advantage is application proxies for just about everything. It also doesn't require changing compile time options to keep state at high volumes.
Its other advantage is, according to a guy a work with, the fact that it has pretty gui screens instead of an ugly old text file. Pretty compelling, eh?
If someone bigger and stronger than us screws us over
Right... if. The old lady suing McDonalds case is usually brought up as an example of an unjustified lawsuit - she spilled the coffee on herself. Of course it was hot, that's how people like coffee. How does serving someone a hot beverage constitue screwing them over?
On a slightly offtopic note, IMHO, the ports tree is superior to ALL linux packaging systems, even apt/dpkg.
Maybe the ports tree has its advantages in the initial installation phase, but do you really think it's comparable for major upgrades (stuff like moving from glibc2 -> glibc2.1, etc.)? Or removing stuff you don't need / want anymore? How about tricky dependency issues?
I ask because in a couple years of using dpkg, it has never let me down, and (almost) always done what I told it to without a hitch...
I cannot believe the people who claim they use Mozilla daily
Calling me a liar? It's been my main browser for months. I like it much better than netscape 4.7. Except for the constant crashing, but builds from the last few days are dramatically more stable.
Any site with a little bit of Javascript looks like crap.
Bullshit. I begrudgingly visit plenty of javascript-based sites, and 70-90% look as good or better than they do in netscape 4.7.
I suspect you've only taken intermittant looks at mozilla, which could easily give you the impression that it's worse than it really is. I sympathize completely with your frustration, and it is unbelievable to me that the mozilla folks haven't narrowed their focus to perfecting the core app, rather than adding the kitchen sink in - "mail, IRC, whatever - sure!" - but believe me, there is a diamond waiting to poke its way out of the lump of coal.
This is the reason I believe Perl needs work before being used for anything serious. ..I [expect to] get an error or thrown Exception for trying to convert a float to a string without a cast
String ssn = rs.getFloat(4);
float cash = rs.getString(1);
These are the errors? You're still thinking in Java if you can't see that the perl equivalent would simply be
($ssn, $cash) = @results;
which presents no float / string conversion problems.
in Perl this error will be allowed to silently propagate through the system causing wasted time later glancing at line-noise-like syntax trying to track down a bug that is due to the typelessness of the language.
The only way this bug (confusing the order of results returned by the SELECT) will creep up to get you is if you don't unit test your methods...
As a student of rhetoric I applaud your masterful argument that a Jeep Cherokee is environmentally friendlier than a Honda Civic, but you sure as hell didn't convince me.
Even if there was something to your 120,000 mile / 180,000 mile equation, you're dead wrong about the lifespan of a small unibodied 4 cylinder.
My 17 year old Tercel, which got me to work in comfort this morning, and the other thousands of early 80s econo cars that are well into the hundreds of thousands of miles, would argue that your durability expectations are way off. Just because a 4-year old american truck starts spitting out parts at 120k doesn't mean that a good japanese car (even one built almost two decades ago) is as poorly constructed. I don't believe that the japanese cars have become less reliable as the years go on, certainly not judging by the state of my friend's 95 civic, which is still in great shape after 200,000 of icy / salted / gravel roads in northern minnesota.
(although I do agree with you that the Chevy Caprice was possibly the pinnacle of American automotive engineering)
if they aren't shown as profitable then they will probably be deep sixed.
There is no question as to the profitability of these cars: the manufacturers lose money on each one. Forget R&D, just the superlight materials alone probably put them in the hole...
The hybrid cars are more about corporate direction, identity, and getting the manufacturer's feet in the door of the future technologies.
For example, I wanted to check out the interview with Orbit, but was denied because I wouldn't let them set a cookie. Why the hell should they have to set a cookie to serve me static content?
Of course, I have no way of knowing if this was Razorfish's decision or IAM's, so don't take this as being for / against the lawsuit.
It does lend some weight to the accusation that razorfish's design has some contract-violating browser dependancy issues, though.
If you intend to encourage people to move to Linux, can a similar idea as TUX be applied to an SQL server to make up for the speed deficit between Linux SQL servers and Microsoft SQL?
OK, the main point of your post - linux kernel modules don't obviously fit with a cross-platform app - is interesting. But where are you coming from with this "SQL servers" question? Assuming that you're talking about databases, you probably should give us some evidence or references. I've been developing database-centric web stuff for a while now, on linux and NT among other platforms, as well as talking to others doing the same, and this is the first I've heard that the microsoft database had any sort of advantage over those availible on linux (other than pretty pictures in the admin interface).
I looked into this a few months ago, and came up with the following understanding of wireless security. I find it easiest to break things down by the path your data takes from your device to the server in question:
1) airwaves (between mobile device and phone tower). This is relatively secure right off the bat, insofar as it's a pain in the ass to intercept phone signals, esp. for CDMA as is used by Sprint (and everyone else but AT&T). If someone really wanted to intercept your signal, they'd probably need something along the lines of a bogus base tower - not so easy for civilians without contacts in the industry to do, but it could be done. Then there is optionally encryption of the data, which happens 1) automatically for AT&T's CDPD network, and 2) optionally on the content layer: HDML and WML both are associated with bastardized versions of SSL, HDTP (handheld device markup layer) and WTLS (wireless transport layer security) respectively. These last two forms of encryption are configured via phone gateways - key size can vary, as can the requirement that they be used at all (IIRC).
2) at the gateway, content is always unencrypted - the wireless encryption needs to be translated to SSL, if in fact the HTTP portion of things is to be encrypted. phone.com makes a big deal about how hard it would be to intercept the unencrypted data, but we'll never really know until we get our hands on gateway software, eh?
3) the internet (or frame relay): typically the phone gateway will then send your packets out over the internet to the server in question, so normal internet security issues apply here. Note that the phone gateways seem to have some abilities to store client certificates, so it may be possible to do various client-authentication type stuff.
As far as the frame relay thing, AT&T also suggests the possibility of running a private line of some sort between their phone gateways and your server, thereby avoiding the uncertainties of the public internet, but that would limit your customers to those with AT&T phones (which is certainly possible for intranet type apps).
Conclusion: There don't seem to be any gaping security holes for low-risk apps such as those that my company had been involved with up until recently, but there are a number of places that a highly-motivated person might be able to sniff / mess with your data - in the air & at the gateway, primarily. If I were interested in fund transfers or the like, I'd want to do some serious investigation into the security policies & practices of wireless phone companies with regards to their gateways, and find out more about the practicalities of intercepting signals in the air.
Even if the software is tight, which we have to take on faith, people operating webservers with wml / hdml content are IIRC dependant on the people operating the gateways to run with a sane configuration - sure, the phones are capable of doing encryption over the airlink, but isn't using / not using crypto a configuration option? So I could be running a server and only allow https connections between my webserver and phone gateways, but I have no way of knowing if the gateways are in turn encrypting the signal between themselves and the phones.
One answer to this is presumably "run your own gateway", but I don't believe this is practical if you want to run a site for the phone-using public, since they will all be coming in via their phone company's gateways (please correct me if I'm wrong about this).
Never trust the client. You should know that HTTP headers can be forged with the hacker tool 'telnet'
On the flip side, if you're the one with the phone, the only way you can keep servers from getting your phone number is by doing through some custom proxy that fudges the header (which is x-up-subno I believe, no http- prefix.)
----------------
just go with the minimal install and add packages
on
Ask 'Ian' From Debian
·
· Score: 1
Much easier to pick the minimal option (whatever it is, it's been a few months since I did an install) and then just use dselect / apt to get the packages you actually use. If you want to decide on a package - by -package level what gets installed, this is the way to go.
Slashdot Mirror
. .
I thought it was more the case that processes under Linux are stellar in comparison to proprietary OS's - so, under Linux, thread-based progs really aren't any faster that process-based ones. (whereas on an OS like NT, a process-based app is useless, so everything has to be multithreaded)
Transactions, yes.
Stored procedures - sometimes yes, sometimes no. There are advantages (increased speed) and disadvantages (decreased flexibility, portability) to using stored procedures. Some shops always use them, some never use them, and the rest mix & match as they see fit. Point being, there definitely are "Real World", well-written db systems that don't heavily use stored procedures.
Not too impressive...
How about Penguin Computing? They seem to offer the equivalent in the rackmount dept., and have similar pricing. What experiences have people had with their stuff?
Compared to what? I've been pricing some SMP rackmount machines for my company, comparing VA Linux, Penguin Computing, Dell, and Compaq, and the first two are significantly cheaper than the second two.
Since we're talking about production systems, I don't think saving a few bucks by rolling our own would be a great idea, even though I do it for my personal machines. When a server pukes a 1 am I'd rather have some company I can complain to, than go second-guess my assembly work.
Caldera for a server? What's big blue thinking?
Maybe in theory... in reality, every WAP phone in the US comes with the phone.com browser, which lies like a dog in its accept header - for example, all the browsers claim to accept text/html, when in fact some of them do not. So, if you're developing web apps that need to work with multiple WAP phones, you need to get your hands dirty by sniffing the user-agent, instead of just looking at the accept header. Stupid stupid stupid.
Not in this life, friend...
For comparison purposes, what checkpoint has to its advantage is application proxies for just about everything. It also doesn't require changing compile time options to keep state at high volumes.
Its other advantage is, according to a guy a work with, the fact that it has pretty gui screens instead of an ugly old text file. Pretty compelling, eh?
Right... if. The old lady suing McDonalds case is usually brought up as an example of an unjustified lawsuit - she spilled the coffee on herself. Of course it was hot, that's how people like coffee. How does serving someone a hot beverage constitue screwing them over?
I have been using Checkpoint to do some rather complex NAT manipulations, and I would love to use ipfilter to do this
Sorry, you're SOL. Ipfilter can't do nat.
On the other hand, ipnat works nicely...
Maybe the ports tree has its advantages in the initial installation phase, but do you really think it's comparable for major upgrades (stuff like moving from glibc2 -> glibc2.1, etc.)? Or removing stuff you don't need / want anymore? How about tricky dependency issues?
I ask because in a couple years of using dpkg, it has never let me down, and (almost) always done what I told it to without a hitch...
Calling me a liar? It's been my main browser for months. I like it much better than netscape 4.7. Except for the constant crashing, but builds from the last few days are dramatically more stable.
Any site with a little bit of Javascript looks like crap.
Bullshit. I begrudgingly visit plenty of javascript-based sites, and 70-90% look as good or better than they do in netscape 4.7.
I suspect you've only taken intermittant looks at mozilla, which could easily give you the impression that it's worse than it really is. I sympathize completely with your frustration, and it is unbelievable to me that the mozilla folks haven't narrowed their focus to perfecting the core app, rather than adding the kitchen sink in - "mail, IRC, whatever - sure!" - but believe me, there is a diamond waiting to poke its way out of the lump of coal.
Preferrably someone with a strong stomach - we don't want anyone vomiting all over their keyboard.
----------------
I don't know if it was the same guy, but this definitely appeared in the questions-to-IM post.
----------------
String ssn = rs.getFloat(4);
float cash = rs.getString(1);
These are the errors? You're still thinking in Java if you can't see that the perl equivalent would simply be
($ssn, $cash) = @results;
which presents no float / string conversion problems.
in Perl this error will be allowed to silently propagate through the system causing wasted time later glancing at line-noise-like syntax trying to track down a bug that is due to the typelessness of the language.
The only way this bug (confusing the order of results returned by the SELECT) will creep up to get you is if you don't unit test your methods...
Wait - if 98 is way way cooler than 2k, why do you despise booting into it?
----------------
Even if there was something to your 120,000 mile / 180,000 mile equation, you're dead wrong about the lifespan of a small unibodied 4 cylinder.
My 17 year old Tercel, which got me to work in comfort this morning, and the other thousands of early 80s econo cars that are well into the hundreds of thousands of miles, would argue that your durability expectations are way off. Just because a 4-year old american truck starts spitting out parts at 120k doesn't mean that a good japanese car (even one built almost two decades ago) is as poorly constructed. I don't believe that the japanese cars have become less reliable as the years go on, certainly not judging by the state of my friend's 95 civic, which is still in great shape after 200,000 of icy / salted / gravel roads in northern minnesota.
(although I do agree with you that the Chevy Caprice was possibly the pinnacle of American automotive engineering)
----------------
There is no question as to the profitability of these cars: the manufacturers lose money on each one. Forget R&D, just the superlight materials alone probably put them in the hole...
The hybrid cars are more about corporate direction, identity, and getting the manufacturer's feet in the door of the future technologies.
----------------
Of course, I have no way of knowing if this was Razorfish's decision or IAM's, so don't take this as being for / against the lawsuit.
It does lend some weight to the accusation that razorfish's design has some contract-violating browser dependancy issues, though.
----------------
OK, the main point of your post - linux kernel modules don't obviously fit with a cross-platform app - is interesting. But where are you coming from with this "SQL servers" question? Assuming that you're talking about databases, you probably should give us some evidence or references. I've been developing database-centric web stuff for a while now, on linux and NT among other platforms, as well as talking to others doing the same, and this is the first I've heard that the microsoft database had any sort of advantage over those availible on linux (other than pretty pictures in the admin interface).
----------------
1) airwaves (between mobile device and phone tower). This is relatively secure right off the bat, insofar as it's a pain in the ass to intercept phone signals, esp. for CDMA as is used by Sprint (and everyone else but AT&T). If someone really wanted to intercept your signal, they'd probably need something along the lines of a bogus base tower - not so easy for civilians without contacts in the industry to do, but it could be done. Then there is optionally encryption of the data, which happens 1) automatically for AT&T's CDPD network, and 2) optionally on the content layer: HDML and WML both are associated with bastardized versions of SSL, HDTP (handheld device markup layer) and WTLS (wireless transport layer security) respectively. These last two forms of encryption are configured via phone gateways - key size can vary, as can the requirement that they be used at all (IIRC).
2) at the gateway, content is always unencrypted - the wireless encryption needs to be translated to SSL, if in fact the HTTP portion of things is to be encrypted. phone.com makes a big deal about how hard it would be to intercept the unencrypted data, but we'll never really know until we get our hands on gateway software, eh?
3) the internet (or frame relay): typically the phone gateway will then send your packets out over the internet to the server in question, so normal internet security issues apply here. Note that the phone gateways seem to have some abilities to store client certificates, so it may be possible to do various client-authentication type stuff.
As far as the frame relay thing, AT&T also suggests the possibility of running a private line of some sort between their phone gateways and your server, thereby avoiding the uncertainties of the public internet, but that would limit your customers to those with AT&T phones (which is certainly possible for intranet type apps).
Conclusion: There don't seem to be any gaping security holes for low-risk apps such as those that my company had been involved with up until recently, but there are a number of places that a highly-motivated person might be able to sniff / mess with your data - in the air & at the gateway, primarily. If I were interested in fund transfers or the like, I'd want to do some serious investigation into the security policies & practices of wireless phone companies with regards to their gateways, and find out more about the practicalities of intercepting signals in the air.
----------------
One answer to this is presumably "run your own gateway", but I don't believe this is practical if you want to run a site for the phone-using public, since they will all be coming in via their phone company's gateways (please correct me if I'm wrong about this).
----------------
On the flip side, if you're the one with the phone, the only way you can keep servers from getting your phone number is by doing through some custom proxy that fudges the header (which is x-up-subno I believe, no http- prefix.)
----------------
----------------