The key word is "native". Xdarwin and X11 are not natively supported on Mac OS X. They're supported through a rather poorly supported compat layer that Apple would prefer to forget about. Apple wants native apps that only run on the Mac, not portable apps that run on any UNIX-like OS, so it's not in their interests to make X work smoothly and quickly on Macs.
There's not really any reason why the Xdarwin wm couldn't present X apps on the dock (grouped by ICCCM client identifier), provide application switching for X apps, and otherwise integrate them a bit better. Cygwin's X server and WM can do it on *windows*, and they don't control the platform. Apple, however, doesn't want this to happen.
That's part of why your X is slow.
The other part is that X11 toolkits like gtk are not written with remote X in mind. They do lots of unnecessary synchronous operations, repeat things a lot, use pixel-based drawing where they could use higher level operations, etc etc etc. The themes and styles they use only make this worse. All the unnecessary waiting, the round trip delays, and the unnecessary streaming of pixel data cause a major performance hit.
You'll probably notice that Qt applications are faster over remote X11. The Qt toolkit tends to handle remote X more efficiently, and with a good app it really shows the difference. Put kmail beside thunderbird and you'll see what I mean.
I do agree that the problems need addressing. One of them will not be addressed, because Apple does not want the same things you want. The other is SLOOOOOWLY being addressed by toolkit developers, though it seems like for every fix two more detrimental changes get included.
Xdarwin hasn't had much attention put into it by Apple. It's very much a second- or third- class citizen under Aqua, and not just in performance terms either.
Your X performance issues have a lot more to do with the Xdarwin server than they do with the x11 protocol and design.
Legitimate complaints met with 'fix it yourself' are what push people to OSX.
Frankly, good riddance.
When I contribute my spare time to developing something - often just for personal interest - and voluntarily make my work available to others for free, I don't appreciate someone coming and whining about how I haven't done enough, especially when they'd never consider doing the same thing themselves. I faced the same problems they did, but I DID SOMETHING ABOUT IT - I learned the languages and tools to work on the problems.
There is no magical difference between "programmer" and "user". There's really only "people willing to learn and do some work" and "people too lazy to do more than demand that others do it for them". It's not like I have spare time coming out my ears or am otherwise better enabled to debug and fix issues, develop features, etc than anybody else - I'm just willing to put the work in and do it.
This type of complainer acts like I owe them something because I've already given them something. It's like they view my time as having no value despite constantly demanding that I spend more and more of it on them. This bewildering attitude of entitlement drives me up the wall and has seriously put me off working on projects I had on the go a couple of times. Having some whining loser complain that I'm not working enough late nights and weekends to finish "their" feature is truly infuriating and completely off-putting. I don't want to finish it, because doing so would benefit them and would reinforce their attitude.
If we "lose" these people to Mac OS X I'll cheer even as my sympathies go out to the Apple folks. At least with Mac OS X the whining loser has paid for something with the understanding that support would be provided. They'll have some legitimate reason to bitch if something doesn't work how they want it to.
Contribution doesn't have to be code; it's really just time, effort, and attention. I think most devs will be much happer to help someone who tries to contribute in any way they're able, be it code, bug investigation, translations, mailing list help, or practically anything else. For example, I'm using postgresql and though I don't contribute code I try to help out by posting detailed answers to questions on the mailing list, including examples where appropriate - not just "RTFM". OTOH I work directly on the code in podofo/podofobrowser, because that's how my time is best spent there.
What I don't do is complain that "someone" should give up their time and do something I'm too lazy to do.
Note that there's nothing wrong with suggesting that something should work a different way. It can be really helpful, especially if decently thought out. There's nothing wrong with expressing a wish for some feature or capability or fix. What's pretty vile is demanding it, as if you're somehow owed it by the people who've already freely given you the use of what they've spent plenty of time and effort on. That's what those people you're saying will be pushed to OS/X are doing... and I'll be happier the sooner we're rid of them.
I'm constantly amazed by people trumpeting the same old line about how network transparency support makes X slow. It stopped being true before some of them were old enough to read and write.
Even if all traffic is forced though loopback TCP/IP by setting DISPLAY to '127.0.0.1:0' (or similar) it still performs quite fine. The network transparency isn't the slowdown.
The slowdown is the toolkits and apps, which miserably fail to consider the influence of network latencies. They issue requests and wait for them to finish before going on to something else. They issue lots of unnecessary requests, do things in inefficient ways, and love lobbing pixels around when higher level drawing instructions would do. Let's not even talk about the themes and styles used by current toolkits and apps (I just got a ~30x speedup out of thunderbird on LTSP by changing the theme!).
People (read: vendors) now frequently refer to flash storage as superior when IOPs are the main issue.
From what I've been able to discern this is actually true only in read-mostly applications and applications where writes are already in neat multiples of the flash erase block size.
If you're doing random small writes your performance is likely to be miserable, because you'll need to erase blocks of flash much larger than the data actually being changed, then rewrite the block with the changed data.
Some apps, like databases, might not care about this if you're able to get their page size to match or exceed that of the underlying storage medium. Whether or not this is possible depends on the database.
For some other uses a log-oriented file system might help, but those have their own issues.
In general, though, flash storage currently only seems to be exciting for random read-mostly applications, which get a revolting performance boost so long as the blocks being written are small enough and scattered enough. For larger contiguous reads hard disks still leave flash in the dust because of their vastly superior raw throughput.
Vendors, however, make a much larger margin on flash disk sales.
I deal with Dell in Australia - in fact I'm typing this on an XPS M1330. While they have their issues, I've been MUCH happier with them than many other vendors I've dealt with and certainly never experienced anything like the issues described here.
I've dealt with Dell for employees buying ultra-cheap laptops, too, so I know it's not some "XPS" thing.
Dell Australia must be a very different organisation. Certainly they bundle basically no crapware with their machines, while I hear horror stories about the standard configuration in the US.
Their hold times aren't great. Their staff could use some product knowledge and better language skills. However, they all want to help, and that's a big improvement over many OEMs.
Additionally, Dell's online support offerings are pretty good. You can actually get complete sets of drivers reliably. They issue driver updates and BIOS fixes. Occasionally their KB is even useful.
When I was having issues that I could demonstrate were an ATi driver bug (by pointing them to the changelog that showed that ATi had fixed it in the new version) Acer remained completely uninterested in providing a driver update for their hardware. "This is the driver that was qualified for the machine" gets tiresome when it's BUGGY and the upstream vendor has released a fix you can't use without your OEM's cooperation. They just could not comprehend why a driver update would be desirable and did not understand why ATi released driver updates. They were also very rude and had a strong "we have your money so why should we care?" attitude.
Dell, on the other hand, just get on with it and release updates for drivers they have to customise for particular hardware like low/mid range video chipsets. They don't even have to be prompted.
They also come out on site and fix things with absolutely no fuss. Got a hardware issue? A tech will be here tomorrow (on time), will know what he's doing, and will have bought the right parts along. This is unique in my experience with OEMs.
Their machines are well enough built that you rarely need the tech, and more importantly seem to generally avoid systemic design faults like inadequate cooling systems. It's nice to know that the laptop you buy will work properly, something I know from personal experience isn't true of everybody.
I do wish they'd improve their phone staff training and make it easier to reach the person you need to talk to, because there is quite a bit of call forwarding before you get anywhere. I'll put up with it in exchange for the rest though.
So.... sure, Dell have their issues, but I've not found another vendor that doesn't rate worse on the suck scale.
"Thou shalt use Hibernate"? Most DBAs hate automatic query generation. Understandably so, as when used by someone who doesn't understand the database it's almost as bad as hand-written queries by the same person.
If you're faced with people who need database access but do not understand databases then the only sensible thing to do is help them use the existing simple interfaces (stored procs, views, etc) and add new ones if they need them.
Giving users read only access will work, with these caveats:
- It may require the investment of quite a bit of developer time ($$) to tighten the security model to isolate restricted parts of the database thoroughly.
- It may require the purchase of new hardware and new software licenses to support the increased load. If the customer has a skilled DBA and the database is well documented this may not be an issue. In practice, however, they'll always end up writing slow and inefficient queries that the DBA must spend time tracing and fixing ($$) or that force the addition of extra capacity.
- Once you give a user read access, they will demand that you introduce more and more levels of restricted access priveleges into the DB structure. This not only costs DB admin time ($$) but also potentially reduces the security of the database by increasing its complexity.
If you give them write access you can expect to spend lots of money:
- Adding lots of extra capacity to cover inefficient queries - On downtime when they break the database - On adding excessively fine-grained security policy to the database -... and on huge amounts of extra tech support because of things the customer breaks.
This is true even in a well designed database with exisitng quite strict access limits and lots of internal checking. The only time write access might even be *remotely* sane is when everything is done through (paranoid) stored procedures anyway. If that's so, it's not much different to offering them access at a web service level instead.
On a database that's not so well designed or is designed for use only by 100% trusted clients (so it omits some sanity checking and priveleges structure) you're in for a nightmare without end.
In other words: Giving the customer direct DB access will cost you money. If you do it, make sure you're prepared to add capacity (and charge the customer accordingly) and dedicate DBA time for direct customer support. Consider giving them access only to a cloned reporting DB. If you offer write access to the main DB do so only through very restricted interfaces or you will face large increases in tech support costs, downtime, etc.
Your best bet is Jabber (XMPP). You'll be familiar with it as Google Talk, but it's a standard protocol that's been around a lot longer than Google's service.
Jabber doesn't seek client-to-client connections. This is a nightmare to achieve with "modern" IPv4 networks, which are full of flakey firewalls, NAT setups of varying levels of insanity, etc. What it does do is let you control your own server or use one you trust.
Jabber/XMPP also supports encryption - both at the transport level using SSL (for if you trust the server but not the network) and at the message level using various public key schemes.
Bad PR in the tech-savvy crowd, sure. All the bandwidth hogs will leave;-) . If they used bandwidth tiered pricing (like everybody in Australia does) they might care, but in places like the US they'll probably be pleased.
They might lose a little bit of business due to lost recommendations, but let's face it... most people have no clue about ISP choice, and will buy whatever advertises the cheapest service with the biggest "speed" number.
Here in Australia the biggest ISP by far is Telstra, who're also the dominant phone provider. They used to be the only phone provider. People use Telstra because their services look cheap when taken at face value, because they advertise widely, and as a default because they're familiar from voice services or have an existing relationship with the customer. Telstra are an awful ISP. Their prices are high, their services are slow, and their "cheap" plans are _really_ expensive because they provide a 200MB to 500MB monthly allowance after which you're charged a steep per-megabyte rate. Got the grandkids over playing games or downloading things? $ouch. Got a big Mac OS X system update? $ouch. Yet people use them, and the vast majority of people sign up with them when they first switch away from dialup.
So, honestly, yes I do think ISPs can get away with doing this sort of thing on a regular basis. For a long time ISPs here used to override proxy cache expiry times set by the originating host, caching pages WAY too long. They used to ignore no cache directives. They used to ignore force-reload from the client. They used to ignore DNS TTL and cache DNS records for at least three days irrespective of the upstream TTL. These practices have fallen off mostly because bandwidth use isn't dominated by cacheable HTTP traffic anymore and because more sites now break totally when faced with that sort of abuse (thus generating support calls), rather than because ISPs ever got in trouble for these practices.
Is being friendly to web caches still relevant in this day and age? How many organizations and/or ISPs actually still have to rely on caching because of a lack of edge bandwidth? Is this really still a concern?
Alas, yes, at least in some places. Australia, for example, where *all* ISPs meter bandwidth and many users are on plans that permit them as little as 500mb or 1GB per month. I have a 24MBit ADSL service with a very reasonable 40GB allowance, but that's on the top end of what you can get and it's pretty pricey.
In that same vain, is the extra CPU overhead of https really a concern in this day and age?.... snip.... Or are you thinking about the CPU overhead on the webserver instead of the client?
I referred to CPU cost on the web server. Crypto accelerator cards help a lot there, though.
I probably spoke poorly by using the term "transparent". As you note, it's already pretty transparent to the user.
What it's not is transparent to the web developer, host, and server.
With STARTLS the restriction of one SSL host per IP address/port pair is lifted. That permits WAY more sites to use SSL, and allows its use without a redirect to a different host and/or port. The user won't see a different URL, there's no protocol string change, etc.
It also allows a client to control whether or not it wants to use TLS, rather than having the server and web designer make those decisions for the client. The server can force the issue, but can also leave the option open to the client where appropriate.
I really like the idea of being able to configure my machine to automatically prefer TLS encryption for HTTP when I'm using, say, a wireless hotspot. I like the idea of being able to set my tech-illiterate parents' laptops up the same way even more.
It'd be particularly nice if combined with a new CA that was fast, cheap and fuss free at the cost of providing poor checking and verification (not like the current ones... *ahem*). Joe Blogger could get his SSL cert for TLS upgrades, and browsers could use it to help ensure encryption and communication integrity without ever suggesting to the user that the presence of the cert and protocol encryption implied anything about the identity or trustworthiness of the site operator.
Currently your options are self-signed (resulting in most browsers screaming loudly to the user), expensive but still poorly verified certs from people like Verisign, or in-between options like openca that most browsers treat as no different from just another self signed cert.
Personally I think the way browsers equate SSL with site trust is fundamentally flawed, and I think they've finally started to realize it, as evidenced by EV certificates and so on.
Because any signature not accompanied by protocol encryption can be stripped by the man in the middle (say, your ISP) without the client knowing it was ever there. Mechanisms to prevent that would also eliminate backward compatibility with older, signature-unaware, browsers, and would end up being essentially HTTPS anyway.
Because of this issue and some related problems I've often wondered about extensions to HTTP to support cryptographically signed pages.
HTTPS is great, but involves a significant CPU cost per page and isn't friendly to web caches.
Signed pages, if static, could be signed once and stored. They'd also be cacheable with all the normal rules.
The main issue is key management. How do you get the signing key? Well, I'm pretty sure the HTTPS certificate key could be used to sign a page, though there might be risks to the integrity of the key. A better way would be to use a single HTTPS request to grab a signing key from the remote site.
Signatures could be just another HTTP header, so browsers without support would never even notice. An alternative would be a HTML comment after the close body tag. The HTTP header, though, would work for related resources like images as well, and for that reason would probably be much better.
Unfortunately, it's all useless because an ISP could trivially strip signatures from HTTP headers or pages if they wanted to mess with the page.
If this sort of thing keeps on happening sites will just have to start offering HTTPS for all communication. The dodgy ISPs will have lower cache hit rates and higher demand for external bandwidth, but they will have done it to themselves.
If only browsers would FINALLY include support for HTTP+TLS and for TLS upgrades, encryption could even be done transparently to the user.
These people usually also have a default admin password in the router that's trivially guessed.
From the router's PPPoE configuration you can get their ISP username (usually in user@domain form).
From there, you can politely email them and inform them that their system is wide open to the world, and cc their ISP's support address on the remote chance they care. There's need to mention how you know their email address, just in case.
I recently did just that for a company that had their wifi network wide open... right across from a foodhall near a university. Ouch. It was presumably the work of a cut-rate "consultant"... the ESSID had been set to the business name, but the default password was still in place and there was no WEP/WPA.
It's a great deal nicer than generating phantom print jobs.
Sure, some people choose to keep their wifi networks open, but they're usually clearly identified as such and don't have machines, printers, etc on the internal network visible to the public.
I think running an open wifi network is crazy anyway. The backwards legal situation around such networks means that in many countries it's your job to prove you *weren't* the person doing something illegal on your 'net connection. ISP contracts also often have terms along the lines of "you take responsibility for what others do using your connection". Not worth the risk IMO unless you want to be the latest important test case. That's one of the reasons I make a point of trying to warn people with open networks... because I know people who've landed up in trouble for things others did with their computers and networks, and I don't want to see it happen to more people unnecessarily.
... was sadly unable to attend due to his death in a tragic shaving accident. In a sad twist of fate his three predecessors in the role met very similar ends.
Pretty much... it's just so stupid, and in such a pettily annoying way. Making entertainment products too annoying to use really gets to me; I'm driven to similar foaming fury by DVD CSS region coding (read: regional price protection with bonus unreliability) with control locks, often misused or incorrectly applied to do things like prevent returning to the menu from the main page.
At least with a DVD you can just rip it or use a player that's been fixed (or written in the first place) to ignore the stupid parts of the standard.
It all comes down to locking me out of products I've bought and making them harder to use. Things like hardware dongles on software are bad enough (can you say single point of failure?) but the very notion of adding highly user-hostile features to entertainment products is nigh incomprehensible.
A 70,000 sold to 350,000 online ratio is pretty extreme, and probably does indicate many lost potential sales. However, it certainly does not mean 280,000 lost potential sales ; many people will be online solely because they could get it for free. I wouldn't be at all surprised if some people bought it because of the greater impact it made and improved word of mouth spread. I know I did. (Then I bought Tribes 2, and wasn't that like a stab to the eye).
I'm sufficiently annoyed about recent "advances" in copy protection - incredibly invasive crap that can make it dangerous to install a game on a machine you also need to get real work done on, the ongoing irritation of finding the damn CD, the head-popping fury involved if the CD/DVD is damaged and your perfectly good install is unusable, the fact that you can't fix it with a no-cd anymore because of the (useful and necessary) cheat protection software like Punkbuster, AND THE KNOWLEDGE THAT PEOPLE WHO PIRATED IT ARE GETTING A BETTER GAMING "EXPERIENCE" THAN YOU ARE, just makes me less likely to buy games.
The online check for serial uniqueness in multiplayer games is a vastly more effective blocker of casual copying and is infinitely less aggravating for the user. So, for multiplayer games like the Battlefield series, why on earth do I need the DVD in the drive? It's just another thing to go wrong, to get lost or damaged, and it's simply annoying. When I'm playing with a friend, if one of us forgot to bring our disc we just launch it, eject the disc, and pass it along. We still both have the required unique serial numbers. How does requiring the disc make any difference, except as something that can be lost/damaged and thus make it harder for me to play the game I bought (another point of failure)?
I have a lot of older games on my laptop. Some I just bought ages ago or have picked up from a bargain bin. Some are from magazine CDs etc, often released as promos when a new version on the same concept is released. Some are from "abandonware" sites. In all cases I can play them without the CD, and it's such a massive improvement in convenience (especially as I exclusively use a laptop; I often don't even have the CDs with me) that I find it harder and harder to care about the new stuff.
Personally, I'm also VASTLY more likely to buy a game I can play with a a couple of my friends who enjoy online gaming. I find solo online play a rather boring experience that's mainly about being repeatedly let down by packs of idiots, and I don't have the time to waste, nor do I play enough, to be interested in the whole clan scene. Being able to play a team or side oriented game with a few friends in close co-operation (in the same room or by voip) makes everything vastly more fun. However, since it now costs us more than $300 (plus expansions, usually) to get set up, we buy and play a LOT fewer games than we would if we could share a copy, or buy extra player licenses at a lower price. For example, if I'd been gaming with the other two when Tribes came out, I guarantee there'd have been at least one sale from me.
I also pirate games to see if they suck before I buy them. I'd feel it less necessary if games and their demos weren't all so buggy at release that some are simply no fun to play, and patch release notes so lacking in detail that it's hard to guess if it might now be in an acceptable state I'm prepared to pay for. One upon a time this would've meant that by the time I bought it there'd been a price drop (as far as I'm concerned that's the price of publishing buggy crap with annoying copy protection) but these days they stay at AU$100 for a year or more anyway. Despite that, I'M STILL MUCH MORE LIKELY TO BUY A GAME IF I CAN BORROW IT, OR PIRATE IT, FIRST
. I've been burned too often by buying games that turn out to be utter crap, or simply buggy enough to be more like work than fun, and am no longer prepared to reward a company for releasing such crap, so I feel it's necessary to try the game before paying for i
It'd be interesting to provide a facility in phones to help make this less prone to privacy issues & semi-legal use by law enforcement. For example, allowing stations to poll passing phones for position and "instantaneous" speed (calculated internally by the phone using, say, the last 3 GPS position checks). Something like that would permit phone responses to omit any unique identifier since there would not be as much of a need to connect multiple responses from a single unit.
An alternative would be to generate a short-lived random ID on the first request by a base station and have it expire after, say, 2 minutes, with no record of it being retained in the phone.
Personally, I'd actually like it if things like phone and vehicle GPS could be used to enforce road safety rules... if I could trust the police to use it only for what they're legally allowed to use it for, rather than for random fishing expeditions and illegal surveillance. Since that'll NEVER happen, I guess the only option is strong anonymity for this sort of data collection.
I have related issues at work, both with employees and outside customers.
Rather than thread trimming (which I consider a lost cause for normal users) the main issue I have is people using e-mail as a file transfer system even for huge and/or urgent files. Think: "I don't know any other way to send files, and why shouldn't e-mail be as good as anything else for sending 100MB files around? Plus, when I get the file from the customer I can just hit "forward" to send it to someone else in the organization. And they can forward it in turn. Sure, those two forwards alone add more than 500MB of data to the mail backups and long-term archives, but why should I care about that? If I'm waiting for an urgent file the customer swears they've sent I'll just come and ask IT to get it for me, they can always do that right?"
Argh. Combine deadlines for getting files with customers on cheap ISPs with overloaded, glacial mail servers and a variety of interesting file size limits and you're in for plenty of fun. Storage and backup management isn't nice either, as I have to yell at the users to get them to delete the forwarded crap from their inbox and sent box. Management rejects all suggestions of mail quotas or timed message expiry even after it's explained that the quota or expiry timer can be specific to the in/sent boxes. E-mail file size limits plus bounce messages that explain how to send files using FTP or web upload are similarly vetoed by management. "management" has a 15GB inbox with 20,000 messages, and uses the desktop as the sole document storage location ( finding things by position, not file name ).
Rather than tell the customer to use our established FTP and web file upload facilities (which are trivial to use on all modern OSes - bascially just "click on this link then drag the file to the window that pops up") the staff tend to ask the customer to come in with a CD or USB key for urgent files. They are aware of, and have used, the FTP and web file upload facilities.
So... sometimes, there's just no fighting the collective stupididy of users when it comes to things like e-mail. E-mail to them is and will remain the way to send files around. Problems can be attributed not to using the wrong tool for the job, but to our mail system being slow and unreliable. Similarly, the fact that they get spam in their inboxes sometimes is a failure of the mail system ( because computers can read and have human judgement, right? ) despite the fact that over 99.8% of delivery attempts are already blocked as spam and the fact that we have to be conservative to avoid dropping legit messages.
If the staff aren't interested in learning how to use their computers better or how to avoid problems they're having by changing their behaviour, and if they have a strong preconceived view of how things should work, you're probably not going to get anywhere without management buy-in to provide reasons for them to care. You're not going to get them to trim quoted messages, use sensible sized signatures, provide an explanation along with a forwarded message, stop using a stupid disclaimer, or any of the other basic e-mail ettiquette issues if they don't care about it. If explaining how that makes them easier to communicate with and makes everybody else's life easier doesn't help, you're going to need help from somebody who they'll listen to, such as a supervisor or company management.
Good luck with that. I'll bet management are the worst offenders.
The pricing issue is also a concern with any non-commodity software too. Countless businesses rely on semi-custom or entirely custom apps for their core operations, and find that the fancy new version 2.0 produced by the vendor (which has promptly dropped support for version 1 entirely) won't run on their existing computers or database - and costs five times as much. You get a bunch of new features you don't need and a forced upgrade so you can keep on doing what you were doing before.
These apps don't go away in quite such an abrupt manner, but it's not much more fun when they do. The very abrubtness with which a web app can vanish is part of what's scary, though, I agree. Imagine a business relying on salesforce.com only to find that either (a) they've been financially struggling for years and abruptly close up shop, or (b) their disaster recovery procedures are inadquate and they're down for weeks after a major crash.
To me, it's that lack of insight into, and control over, web apps that's the real worry. You can't make sure they conform to reasonable standards of backup procedures or security protocols. Scary stuff, especially when you're giving them customer data.
Beyond the obvious issue of the need for continuous connectivity, there are some serious issues with hosted apps that make them much less attractive than they could be.
The biggest one, blessing and curse in one, is that there's a 1:1 relationship between client app and service. The hosted app provider controls the client used to access the app as well, something that tends to result in smoother integration, but also a lack of choice.
Consider mail. Few of us would like to have a specific mail client forced on us by an ISP - yet that's exactly what web mail providers do. For mail, people are happy enough to just move to the provider with a client they're happy with, but that won't be possible for all types of app. I'm very dubious about the unification of storage, communication protocol and client into a single entity.
Web apps also make it harder to apply policy. How can you, with web apps, have a shared working directory with snapshots taken every five minutes (aged out progressively) that gets automatically archived into another part of your system & indexed at the end of the week? It's not easy, that's for sure. Businesses with access control requirements, data retention issues, etc also face issues.
Even if the provider tries to take care of those problems, they'll have a hard time making it easy to integrate things like archival with the rest of your network.
The admin also tends to lose insight into the system with web apps. If I hosted my business's mail with Google, I wouldn't get access to the mail logs, control over spam filter sensitivity, or other important facilities. That's not inherently the case, in that Google could offer these facilities, but in general web apps tend to take more of a black box approach.
In short... they're OK for consumer use and for specialized tasks, but for general work I doubt I'll be interested in web apps for quite a while.
This - alas - doesn't solve the need for developers to have access to Mac OS X for testing and porting their apps. Especially OSS developers, who may not want to fork out for a mac just for testing.
With luck Apple will at some point release a developer-only Mac OS X client OS (perhaps one without all the apps it normally comes with etc, just a barebones OS) for testing apps. They'd still face some risk people would use it for other things, but people who do so are likely to want to jump to real Apple gear anyway.
I'm not holding my breath, of course, since I value my life.
Yes, they work great - so long as you wait long enough for them to release a new version or at least a patch for compatibility before upgrading your production macs to a new OS. Going from 10.2 to 10.4, for example, was... interesting.
Since production setups are generally well tested before any software changes that's not the end of the world. However, if you happen to be forced to buy new / replacement hardware while you're not tracking the latest Mac OS, you're likely to land up with a machine that just refuses to run the older OS. Your older version apps often don't like the new OS - they'll usually work, but with bugs and crashes aplenty.
The time this bit me worst was before we were able to move to Mac OS X . My work was using an eMac for one user who didn't need good colour etc because it was the last Mac OS 9 machine available. It died, as eMacs tend to do, so I sent it off for warranty repair. They sent back a replacement - that could no longer boot Mac OS 9. New motherboard. Sorry.
That's a bit of an extreme case. Nonetheless, I have had enough compatibility issues that I'm wary of each Mac OS X update and wish to wait a while before upgrading, especially if we haven't done a CS & Quark upgrade lately. (Yes, I'd like to drop Quark entirely, but the DTP staff are only now making scared baby-steps with InDesign).
As a software developer I understand this situation, and I'm not upset by it. I'd prefer them to break compatibility to improve reliability, fix bugs, introduce useful new capabilities, etc. I'd like to be told when it happens, but I know how hard that is too. I'm also well aware that _well_ _written_ apps that lack dodgy workarounds and hacks don't tend to suffer too many issues with upgrades (on ANY platform) - but Adobe and especially Quark aren't known for avoiding dodgy hacks and workarounds.
Slashdot Mirror
(sorry for the extra reply)
The key word is "native". Xdarwin and X11 are not natively supported on Mac OS X. They're supported through a rather poorly supported compat layer that Apple would prefer to forget about. Apple wants native apps that only run on the Mac, not portable apps that run on any UNIX-like OS, so it's not in their interests to make X work smoothly and quickly on Macs.
There's not really any reason why the Xdarwin wm couldn't present X apps on the dock (grouped by ICCCM client identifier), provide application switching for X apps, and otherwise integrate them a bit better. Cygwin's X server and WM can do it on *windows*, and they don't control the platform. Apple, however, doesn't want this to happen.
That's part of why your X is slow.
The other part is that X11 toolkits like gtk are not written with remote X in mind. They do lots of unnecessary synchronous operations, repeat things a lot, use pixel-based drawing where they could use higher level operations, etc etc etc. The themes and styles they use only make this worse. All the unnecessary waiting, the round trip delays, and the unnecessary streaming of pixel data cause a major performance hit.
You'll probably notice that Qt applications are faster over remote X11. The Qt toolkit tends to handle remote X more efficiently, and with a good app it really shows the difference. Put kmail beside thunderbird and you'll see what I mean.
I do agree that the problems need addressing. One of them will not be addressed, because Apple does not want the same things you want. The other is SLOOOOOWLY being addressed by toolkit developers, though it seems like for every fix two more detrimental changes get included.
Xdarwin hasn't had much attention put into it by Apple. It's very much a second- or third- class citizen under Aqua, and not just in performance terms either.
Your X performance issues have a lot more to do with the Xdarwin server than they do with the x11 protocol and design.
Legitimate complaints met with 'fix it yourself' are what push people to OSX.
... and I'll be happier the sooner we're rid of them.
Frankly, good riddance.
When I contribute my spare time to developing something - often just for personal interest - and voluntarily make my work available to others for free, I don't appreciate someone coming and whining about how I haven't done enough, especially when they'd never consider doing the same thing themselves. I faced the same problems they did, but I DID SOMETHING ABOUT IT - I learned the languages and tools to work on the problems.
There is no magical difference between "programmer" and "user". There's really only "people willing to learn and do some work" and "people too lazy to do more than demand that others do it for them". It's not like I have spare time coming out my ears or am otherwise better enabled to debug and fix issues, develop features, etc than anybody else - I'm just willing to put the work in and do it.
This type of complainer acts like I owe them something because I've already given them something. It's like they view my time as having no value despite constantly demanding that I spend more and more of it on them. This bewildering attitude of entitlement drives me up the wall and has seriously put me off working on projects I had on the go a couple of times. Having some whining loser complain that I'm not working enough late nights and weekends to finish "their" feature is truly infuriating and completely off-putting. I don't want to finish it, because doing so would benefit them and would reinforce their attitude.
If we "lose" these people to Mac OS X I'll cheer even as my sympathies go out to the Apple folks. At least with Mac OS X the whining loser has paid for something with the understanding that support would be provided. They'll have some legitimate reason to bitch if something doesn't work how they want it to.
Contribution doesn't have to be code; it's really just time, effort, and attention. I think most devs will be much happer to help someone who tries to contribute in any way they're able, be it code, bug investigation, translations, mailing list help, or practically anything else. For example, I'm using postgresql and though I don't contribute code I try to help out by posting detailed answers to questions on the mailing list, including examples where appropriate - not just "RTFM". OTOH I work directly on the code in podofo/podofobrowser, because that's how my time is best spent there.
What I don't do is complain that "someone" should give up their time and do something I'm too lazy to do.
Note that there's nothing wrong with suggesting that something should work a different way. It can be really helpful, especially if decently thought out. There's nothing wrong with expressing a wish for some feature or capability or fix. What's pretty vile is demanding it, as if you're somehow owed it by the people who've already freely given you the use of what they've spent plenty of time and effort on. That's what those people you're saying will be pushed to OS/X are doing
I'm constantly amazed by people trumpeting the same old line about how network transparency support makes X slow. It stopped being true before some of them were old enough to read and write.
Even if all traffic is forced though loopback TCP/IP by setting DISPLAY to '127.0.0.1:0' (or similar) it still performs quite fine. The network transparency isn't the slowdown.
The slowdown is the toolkits and apps, which miserably fail to consider the influence of network latencies. They issue requests and wait for them to finish before going on to something else. They issue lots of unnecessary requests, do things in inefficient ways, and love lobbing pixels around when higher level drawing instructions would do. Let's not even talk about the themes and styles used by current toolkits and apps (I just got a ~30x speedup out of thunderbird on LTSP by changing the theme!).
*argh*
People (read: vendors) now frequently refer to flash storage as superior when IOPs are the main issue.
From what I've been able to discern this is actually true only in read-mostly applications and applications where writes are already in neat multiples of the flash erase block size.
If you're doing random small writes your performance is likely to be miserable, because you'll need to erase blocks of flash much larger than the data actually being changed, then rewrite the block with the changed data.
Some apps, like databases, might not care about this if you're able to get their page size to match or exceed that of the underlying storage medium. Whether or not this is possible depends on the database.
For some other uses a log-oriented file system might help, but those have their own issues.
In general, though, flash storage currently only seems to be exciting for random read-mostly applications, which get a revolting performance boost so long as the blocks being written are small enough and scattered enough. For larger contiguous reads hard disks still leave flash in the dust because of their vastly superior raw throughput.
Vendors, however, make a much larger margin on flash disk sales.
This article (PDF) may be of interest:
Understanding Flash SSD performance
(google text version).
I deal with Dell in Australia - in fact I'm typing this on an XPS M1330. While they have their issues, I've been MUCH happier with them than many other vendors I've dealt with and certainly never experienced anything like the issues described here.
.... sure, Dell have their issues, but I've not found another vendor that doesn't rate worse on the suck scale.
I've dealt with Dell for employees buying ultra-cheap laptops, too, so I know it's not some "XPS" thing.
Dell Australia must be a very different organisation. Certainly they bundle basically no crapware with their machines, while I hear horror stories about the standard configuration in the US.
Their hold times aren't great. Their staff could use some product knowledge and better language skills. However, they all want to help, and that's a big improvement over many OEMs.
Additionally, Dell's online support offerings are pretty good. You can actually get complete sets of drivers reliably. They issue driver updates and BIOS fixes. Occasionally their KB is even useful.
When I was having issues that I could demonstrate were an ATi driver bug (by pointing them to the changelog that showed that ATi had fixed it in the new version) Acer remained completely uninterested in providing a driver update for their hardware. "This is the driver that was qualified for the machine" gets tiresome when it's BUGGY and the upstream vendor has released a fix you can't use without your OEM's cooperation. They just could not comprehend why a driver update would be desirable and did not understand why ATi released driver updates. They were also very rude and had a strong "we have your money so why should we care?" attitude.
Dell, on the other hand, just get on with it and release updates for drivers they have to customise for particular hardware like low/mid range video chipsets. They don't even have to be prompted.
They also come out on site and fix things with absolutely no fuss. Got a hardware issue? A tech will be here tomorrow (on time), will know what he's doing, and will have bought the right parts along. This is unique in my experience with OEMs.
Their machines are well enough built that you rarely need the tech, and more importantly seem to generally avoid systemic design faults like inadequate cooling systems. It's nice to know that the laptop you buy will work properly, something I know from personal experience isn't true of everybody.
I do wish they'd improve their phone staff training and make it easier to reach the person you need to talk to, because there is quite a bit of call forwarding before you get anywhere. I'll put up with it in exchange for the rest though.
So
... which uses HSQLDB, a Java database.
The OP has eliminated most of the useful options with the criteria specified.
How else would you do it?
"Thou shalt use Hibernate"? Most DBAs hate automatic query generation. Understandably so, as when used by someone who doesn't understand the database it's almost as bad as hand-written queries by the same person.
If you're faced with people who need database access but do not understand databases then the only sensible thing to do is help them use the existing simple interfaces (stored procs, views, etc) and add new ones if they need them.
Frame it in business terms.
... and on huge amounts of extra tech support because of things the customer breaks.
Giving users read only access will work, with these caveats:
- It may require the investment of quite a bit of developer time ($$) to tighten the security model to isolate restricted parts of the database thoroughly.
- It may require the purchase of new hardware and new software licenses to support the increased load. If the customer has a skilled DBA and the database is well documented this may not be an issue. In practice, however, they'll always end up writing slow and inefficient queries that the DBA must spend time tracing and fixing ($$) or that force the addition of extra capacity.
- Once you give a user read access, they will demand that you introduce more and more levels of restricted access priveleges into the DB structure. This not only costs DB admin time ($$) but also potentially reduces the security of the database by increasing its complexity.
If you give them write access you can expect to spend lots of money:
- Adding lots of extra capacity to cover inefficient queries
- On downtime when they break the database
- On adding excessively fine-grained security policy to the database
-
This is true even in a well designed database with exisitng quite strict access limits and lots of internal checking. The only time write access might even be *remotely* sane is when everything is done through (paranoid) stored procedures anyway. If that's so, it's not much different to offering them access at a web service level instead.
On a database that's not so well designed or is designed for use only by 100% trusted clients (so it omits some sanity checking and priveleges structure) you're in for a nightmare without end.
In other words: Giving the customer direct DB access will cost you money. If you do it, make sure you're prepared to add capacity (and charge the customer accordingly) and dedicate DBA time for direct customer support. Consider giving them access only to a cloned reporting DB. If you offer write access to the main DB do so only through very restricted interfaces or you will face large increases in tech support costs, downtime, etc.
Your best bet is Jabber (XMPP). You'll be familiar with it as Google Talk, but it's a standard protocol that's been around a lot longer than Google's service.
Jabber doesn't seek client-to-client connections. This is a nightmare to achieve with "modern" IPv4 networks, which are full of flakey firewalls, NAT setups of varying levels of insanity, etc. What it does do is let you control your own server or use one you trust.
There actually is a
direct client to client facility for Jabber, but I don't know how widely the extension is implemented.
Jabber/XMPP also supports encryption - both at the transport level using SSL (for if you trust the server but not the network) and at the message level using various public key schemes.
Bad PR in the tech-savvy crowd, sure. All the bandwidth hogs will leave ;-) . If they used bandwidth tiered pricing (like everybody in Australia does) they might care, but in places like the US they'll probably be pleased.
... most people have no clue about ISP choice, and will buy whatever advertises the cheapest service with the biggest "speed" number.
They might lose a little bit of business due to lost recommendations, but let's face it
Here in Australia the biggest ISP by far is Telstra, who're also the dominant phone provider. They used to be the only phone provider. People use Telstra because their services look cheap when taken at face value, because they advertise widely, and as a default because they're familiar from voice services or have an existing relationship with the customer. Telstra are an awful ISP. Their prices are high, their services are slow, and their "cheap" plans are _really_ expensive because they provide a 200MB to 500MB monthly allowance after which you're charged a steep per-megabyte rate. Got the grandkids over playing games or downloading things? $ouch. Got a big Mac OS X system update? $ouch. Yet people use them, and the vast majority of people sign up with them when they first switch away from dialup.
So, honestly, yes I do think ISPs can get away with doing this sort of thing on a regular basis. For a long time ISPs here used to override proxy cache expiry times set by the originating host, caching pages WAY too long. They used to ignore no cache directives. They used to ignore force-reload from the client. They used to ignore DNS TTL and cache DNS records for at least three days irrespective of the upstream TTL. These practices have fallen off mostly because bandwidth use isn't dominated by cacheable HTTP traffic anymore and because more sites now break totally when faced with that sort of abuse (thus generating support calls), rather than because ISPs ever got in trouble for these practices.
Is being friendly to web caches still relevant in this day and age? How many organizations and/or ISPs actually still have to rely on caching because of a lack of edge bandwidth? Is this really still a concern?
Alas, yes, at least in some places. Australia, for example, where *all* ISPs meter bandwidth and many users are on plans that permit them as little as 500mb or 1GB per month. I have a 24MBit ADSL service with a very reasonable 40GB allowance, but that's on the top end of what you can get and it's pretty pricey.
In that same vain, is the extra CPU overhead of https really a concern in this day and age? .... snip .... Or are you thinking about the CPU overhead on the webserver instead of the client?
I referred to CPU cost on the web server. Crypto accelerator cards help a lot there, though.
I probably spoke poorly by using the term "transparent". As you note, it's already pretty transparent to the user.
What it's not is transparent to the web developer, host, and server.
With STARTLS the restriction of one SSL host per IP address/port pair is lifted. That permits WAY more sites to use SSL, and allows its use without a redirect to a different host and/or port. The user won't see a different URL, there's no protocol string change, etc.
It also allows a client to control whether or not it wants to use TLS, rather than having the server and web designer make those decisions for the client. The server can force the issue, but can also leave the option open to the client where appropriate.
I really like the idea of being able to configure my machine to automatically prefer TLS encryption for HTTP when I'm using, say, a wireless hotspot. I like the idea of being able to set my tech-illiterate parents' laptops up the same way even more.
It'd be particularly nice if combined with a new CA that was fast, cheap and fuss free at the cost of providing poor checking and verification (not like the current ones... *ahem*). Joe Blogger could get his SSL cert for TLS upgrades, and browsers could use it to help ensure encryption and communication integrity without ever suggesting to the user that the presence of the cert and protocol encryption implied anything about the identity or trustworthiness of the site operator.
Currently your options are self-signed (resulting in most browsers screaming loudly to the user), expensive but still poorly verified certs from people like Verisign, or in-between options like openca that most browsers treat as no different from just another self signed cert.
Personally I think the way browsers equate SSL with site trust is fundamentally flawed, and I think they've finally started to realize it, as evidenced by EV certificates and so on.
Because any signature not accompanied by protocol encryption can be stripped by the man in the middle (say, your ISP) without the client knowing it was ever there. Mechanisms to prevent that would also eliminate backward compatibility with older, signature-unaware, browsers, and would end up being essentially HTTPS anyway.
Because of this issue and some related problems I've often wondered about extensions to HTTP to support cryptographically signed pages.
HTTPS is great, but involves a significant CPU cost per page and isn't friendly to web caches.
Signed pages, if static, could be signed once and stored. They'd also be cacheable with all the normal rules.
The main issue is key management. How do you get the signing key? Well, I'm pretty sure the HTTPS certificate key could be used to sign a page, though there might be risks to the integrity of the key. A better way would be to use a single HTTPS request to grab a signing key from the remote site.
Signatures could be just another HTTP header, so browsers without support would never even notice. An alternative would be a HTML comment after the close body tag. The HTTP header, though, would work for related resources like images as well, and for that reason would probably be much better.
Unfortunately, it's all useless because an ISP could trivially strip signatures from HTTP headers or pages if they wanted to mess with the page.
If this sort of thing keeps on happening sites will just have to start offering HTTPS for all communication. The dodgy ISPs will have lower cache hit rates and higher demand for external bandwidth, but they will have done it to themselves.
If only browsers would FINALLY include support for HTTP+TLS and for TLS upgrades, encryption could even be done transparently to the user.
These people usually also have a default admin password in the router that's trivially guessed.
... right across from a foodhall near a university. Ouch. It was presumably the work of a cut-rate "consultant" ... the ESSID had been set to the business name, but the default password was still in place and there was no WEP/WPA.
From the router's PPPoE configuration you can get their ISP username (usually in user@domain form).
From there, you can politely email them and inform them that their system is wide open to the world, and cc their ISP's support address on the remote chance they care. There's need to mention how you know their email address, just in case.
I recently did just that for a company that had their wifi network wide open
It's a great deal nicer than generating phantom print jobs.
Sure, some people choose to keep their wifi networks open, but they're usually clearly identified as such and don't have machines, printers, etc on the internal network visible to the public.
I think running an open wifi network is crazy anyway. The backwards legal situation around such networks means that in many countries it's your job to prove you *weren't* the person doing something illegal on your 'net connection. ISP contracts also often have terms along the lines of "you take responsibility for what others do using your connection". Not worth the risk IMO unless you want to be the latest important test case. That's one of the reasons I make a point of trying to warn people with open networks... because I know people who've landed up in trouble for things others did with their computers and networks, and I don't want to see it happen to more people unnecessarily.
... was sadly unable to attend due to his death in a tragic shaving accident. In a sad twist of fate his three predecessors in the role met very similar ends.
No new delegate has yet been named.
Pretty much ... it's just so stupid, and in such a pettily annoying way. Making entertainment products too annoying to use really gets to me; I'm driven to similar foaming fury by DVD CSS region coding (read: regional price protection with bonus unreliability) with control locks, often misused or incorrectly applied to do things like prevent returning to the menu from the main page.
At least with a DVD you can just rip it or use a player that's been fixed (or written in the first place) to ignore the stupid parts of the standard.
It all comes down to locking me out of products I've bought and making them harder to use. Things like hardware dongles on software are bad enough (can you say single point of failure?) but the very notion of adding highly user-hostile features to entertainment products is nigh incomprehensible.
A 70,000 sold to 350,000 online ratio is pretty extreme, and probably does indicate many lost potential sales. However, it certainly does not mean 280,000 lost potential sales ; many people will be online solely because they could get it for free. I wouldn't be at all surprised if some people bought it because of the greater impact it made and improved word of mouth spread. I know I did. (Then I bought Tribes 2, and wasn't that like a stab to the eye).
I'm sufficiently annoyed about recent "advances" in copy protection - incredibly invasive crap that can make it dangerous to install a game on a machine you also need to get real work done on, the ongoing irritation of finding the damn CD, the head-popping fury involved if the CD/DVD is damaged and your perfectly good install is unusable, the fact that you can't fix it with a no-cd anymore because of the (useful and necessary) cheat protection software like Punkbuster, AND THE KNOWLEDGE THAT PEOPLE WHO PIRATED IT ARE GETTING A BETTER GAMING "EXPERIENCE" THAN YOU ARE, just makes me less likely to buy games.
The online check for serial uniqueness in multiplayer games is a vastly more effective blocker of casual copying and is infinitely less aggravating for the user. So, for multiplayer games like the Battlefield series, why on earth do I need the DVD in the drive? It's just another thing to go wrong, to get lost or damaged, and it's simply annoying. When I'm playing with a friend, if one of us forgot to bring our disc we just launch it, eject the disc, and pass it along. We still both have the required unique serial numbers. How does requiring the disc make any difference, except as something that can be lost/damaged and thus make it harder for me to play the game I bought (another point of failure)?
I have a lot of older games on my laptop. Some I just bought ages ago or have picked up from a bargain bin. Some are from magazine CDs etc, often released as promos when a new version on the same concept is released. Some are from "abandonware" sites. In all cases I can play them without the CD, and it's such a massive improvement in convenience (especially as I exclusively use a laptop; I often don't even have the CDs with me) that I find it harder and harder to care about the new stuff.
Personally, I'm also VASTLY more likely to buy a game I can play with a a couple of my friends who enjoy online gaming. I find solo online play a rather boring experience that's mainly about being repeatedly let down by packs of idiots, and I don't have the time to waste, nor do I play enough, to be interested in the whole clan scene. Being able to play a team or side oriented game with a few friends in close co-operation (in the same room or by voip) makes everything vastly more fun. However, since it now costs us more than $300 (plus expansions, usually) to get set up, we buy and play a LOT fewer games than we would if we could share a copy, or buy extra player licenses at a lower price. For example, if I'd been gaming with the other two when Tribes came out, I guarantee there'd have been at least one sale from me.
I also pirate games to see if they suck before I buy them. I'd feel it less necessary if games and their demos weren't all so buggy at release that some are simply no fun to play, and patch release notes so lacking in detail that it's hard to guess if it might now be in an acceptable state I'm prepared to pay for. One upon a time this would've meant that by the time I bought it there'd been a price drop (as far as I'm concerned that's the price of publishing buggy crap with annoying copy protection) but these days they stay at AU$100 for a year or more anyway. Despite that, I'M STILL MUCH MORE LIKELY TO BUY A GAME IF I CAN BORROW IT, OR PIRATE IT, FIRST
. I've been burned too often by buying games that turn out to be utter crap, or simply buggy enough to be more like work than fun, and am no longer prepared to reward a company for releasing such crap, so I feel it's necessary to try the game before paying for i
It'd be interesting to provide a facility in phones to help make this less prone to privacy issues & semi-legal use by law enforcement. For example, allowing stations to poll passing phones for position and "instantaneous" speed (calculated internally by the phone using, say, the last 3 GPS position checks). Something like that would permit phone responses to omit any unique identifier since there would not be as much of a need to connect multiple responses from a single unit.
An alternative would be to generate a short-lived random ID on the first request by a base station and have it expire after, say, 2 minutes, with no record of it being retained in the phone.
Personally, I'd actually like it if things like phone and vehicle GPS could be used to enforce road safety rules... if I could trust the police to use it only for what they're legally allowed to use it for, rather than for random fishing expeditions and illegal surveillance. Since that'll NEVER happen, I guess the only option is strong anonymity for this sort of data collection.
I have related issues at work, both with employees and outside customers.
... sometimes, there's just no fighting the collective stupididy of users when it comes to things like e-mail. E-mail to them is and will remain the way to send files around. Problems can be attributed not to using the wrong tool for the job, but to our mail system being slow and unreliable. Similarly, the fact that they get spam in their inboxes sometimes is a failure of the mail system ( because computers can read and have human judgement, right? ) despite the fact that over 99.8% of delivery attempts are already blocked as spam and the fact that we have to be conservative to avoid dropping legit messages.
Rather than thread trimming (which I consider a lost cause for normal users) the main issue I have is people using e-mail as a file transfer system even for huge and/or urgent files. Think: "I don't know any other way to send files, and why shouldn't e-mail be as good as anything else for sending 100MB files around? Plus, when I get the file from the customer I can just hit "forward" to send it to someone else in the organization. And they can forward it in turn. Sure, those two forwards alone add more than 500MB of data to the mail backups and long-term archives, but why should I care about that? If I'm waiting for an urgent file the customer swears they've sent I'll just come and ask IT to get it for me, they can always do that right?"
Argh. Combine deadlines for getting files with customers on cheap ISPs with overloaded, glacial mail servers and a variety of interesting file size limits and you're in for plenty of fun. Storage and backup management isn't nice either, as I have to yell at the users to get them to delete the forwarded crap from their inbox and sent box. Management rejects all suggestions of mail quotas or timed message expiry even after it's explained that the quota or expiry timer can be specific to the in/sent boxes. E-mail file size limits plus bounce messages that explain how to send files using FTP or web upload are similarly vetoed by management. "management" has a 15GB inbox with 20,000 messages, and uses the desktop as the sole document storage location ( finding things by position, not file name ).
Rather than tell the customer to use our established FTP and web file upload facilities (which are trivial to use on all modern OSes - bascially just "click on this link then drag the file to the window that pops up") the staff tend to ask the customer to come in with a CD or USB key for urgent files. They are aware of, and have used, the FTP and web file upload facilities.
So
If the staff aren't interested in learning how to use their computers better or how to avoid problems they're having by changing their behaviour, and if they have a strong preconceived view of how things should work, you're probably not going to get anywhere without management buy-in to provide reasons for them to care. You're not going to get them to trim quoted messages, use sensible sized signatures, provide an explanation along with a forwarded message, stop using a stupid disclaimer, or any of the other basic e-mail ettiquette issues if they don't care about it. If explaining how that makes them easier to communicate with and makes everybody else's life easier doesn't help, you're going to need help from somebody who they'll listen to, such as a supervisor or company management.
Good luck with that. I'll bet management are the worst offenders.
The pricing issue is also a concern with any non-commodity software too. Countless businesses rely on semi-custom or entirely custom apps for their core operations, and find that the fancy new version 2.0 produced by the vendor (which has promptly dropped support for version 1 entirely) won't run on their existing computers or database - and costs five times as much. You get a bunch of new features you don't need and a forced upgrade so you can keep on doing what you were doing before.
These apps don't go away in quite such an abrupt manner, but it's not much more fun when they do. The very abrubtness with which a web app can vanish is part of what's scary, though, I agree. Imagine a business relying on salesforce.com only to find that either (a) they've been financially struggling for years and abruptly close up shop, or (b) their disaster recovery procedures are inadquate and they're down for weeks after a major crash.
To me, it's that lack of insight into, and control over, web apps that's the real worry. You can't make sure they conform to reasonable standards of backup procedures or security protocols. Scary stuff, especially when you're giving them customer data.
Beyond the obvious issue of the need for continuous connectivity, there are some serious issues with hosted apps that make them much less attractive than they could be.
... they're OK for consumer use and for specialized tasks, but for general work I doubt I'll be interested in web apps for quite a while.
The biggest one, blessing and curse in one, is that there's a 1:1 relationship between client app and service. The hosted app provider controls the client used to access the app as well, something that tends to result in smoother integration, but also a lack of choice.
Consider mail. Few of us would like to have a specific mail client forced on us by an ISP - yet that's exactly what web mail providers do. For mail, people are happy enough to just move to the provider with a client they're happy with, but that won't be possible for all types of app. I'm very dubious about the unification of storage, communication protocol and client into a single entity.
Web apps also make it harder to apply policy. How can you, with web apps, have a shared working directory with snapshots taken every five minutes (aged out progressively) that gets automatically archived into another part of your system & indexed at the end of the week? It's not easy, that's for sure. Businesses with access control requirements, data retention issues, etc also face issues.
Even if the provider tries to take care of those problems, they'll have a hard time making it easy to integrate things like archival with the rest of your network.
The admin also tends to lose insight into the system with web apps. If I hosted my business's mail with Google, I wouldn't get access to the mail logs, control over spam filter sensitivity, or other important facilities. That's not inherently the case, in that Google could offer these facilities, but in general web apps tend to take more of a black box approach.
In short
--
Craig Ringer
This - alas - doesn't solve the need for developers to have access to Mac OS X for testing and porting their apps. Especially OSS developers, who may not want to fork out for a mac just for testing.
With luck Apple will at some point release a developer-only Mac OS X client OS (perhaps one without all the apps it normally comes with etc, just a barebones OS) for testing apps. They'd still face some risk people would use it for other things, but people who do so are likely to want to jump to real Apple gear anyway.
I'm not holding my breath, of course, since I value my life.
Yes, they work great - so long as you wait long enough for them to release a new version or at least a patch for compatibility before upgrading your production macs to a new OS. Going from 10.2 to 10.4, for example, was ... interesting.
Since production setups are generally well tested before any software changes that's not the end of the world. However, if you happen to be forced to buy new / replacement hardware while you're not tracking the latest Mac OS, you're likely to land up with a machine that just refuses to run the older OS. Your older version apps often don't like the new OS - they'll usually work, but with bugs and crashes aplenty.
The time this bit me worst was before we were able to move to Mac OS X . My work was using an eMac for one user who didn't need good colour etc because it was the last Mac OS 9 machine available. It died, as eMacs tend to do, so I sent it off for warranty repair. They sent back a replacement - that could no longer boot Mac OS 9. New motherboard. Sorry.
That's a bit of an extreme case. Nonetheless, I have had enough compatibility issues that I'm wary of each Mac OS X update and wish to wait a while before upgrading, especially if we haven't done a CS & Quark upgrade lately. (Yes, I'd like to drop Quark entirely, but the DTP staff are only now making scared baby-steps with InDesign).
As a software developer I understand this situation, and I'm not upset by it. I'd prefer them to break compatibility to improve reliability, fix bugs, introduce useful new capabilities, etc. I'd like to be told when it happens, but I know how hard that is too. I'm also well aware that _well_ _written_ apps that lack dodgy workarounds and hacks don't tend to suffer too many issues with upgrades (on ANY platform) - but Adobe and especially Quark aren't known for avoiding dodgy hacks and workarounds.