Flash isn't perfect under Linux, but it does work pretty well. It used to be nightmarish when it when through its long unmaintained-for-Linux phase, but for a couple of years now it's been pretty solid on mainstream distros.
There can be problems if you use anything unusual, or run a 64-bit native system.
That said, I have Flash installed in Firefox on my X11 thin clients at work with no issues beyond what you'd expect when combining software written by idiots (most flash movies) with low graphical performance hosts (X11 thin clients). The worst issue I see is that it can slow down the client a bit when playing animations created by "designers" who think everyone's using a Core 2 Duo machine with a high performance 3D accelerated video card. Usually ads.
Even then, nothing crashes and at worst the browser tab/session can be closed. The flashblock extension has made life a little nicer though by letting the users choose whether they want to view flash, rather than being forced into viewing lots of badly-written flash ad movies as they try to get real work done. I find the same thing to be necessary on my Core 2 Duo WinXP laptop.
In short - recent Flash versions are pretty darn good.
I use hard mounts (the default) but have not been setting the `intr' flag. However, if a process always hangs when accessing a file that doesn't help - whether the process is unkillable, or just can't run, if the user's session depends on it the user's still down for the count.
I force NFS version 3 and sync mode (because these are rw shares).
The worst problem I've had is with home directories, but even now that I export a logical volume to the Xen guest for home dirs instead, I still have other NFS related issues. Hopefully they'll improve over time, but it's pretty frustrating for such an old and core service. Maybe the NFSv4 work will help clean up and improve the Linux NFS implementation.
CIFS with posix extensions does look promising. I find this depressing given how awful the CIFS protocol is... but if it works, it works.
Anyhow, thanks for the tips. I'll set the intr option, and I think I'll actually switch to soft mounts so I can force a disconnect when the NFS session goes brain dead.
I've been pretty happy with Linux in general, but I'm not thrilled with its network file system support. In particular, NFS has been prone to occasionally leave a particular file in a state where any process that tries to access it hangs in the kernel, and only a system reboot (!) fixes the problem. I'm hoping this was fixed between 2.6.10 and 2.6.20, which I've just upgraded our systems to.
Xen is also less solid than I'd like, at least on the dual Xeon server board I'm running it on. I've had a couple of bizarre issues with Xen 3.0 now that make me wonder if I should go back (again - I tried an older 3.0 before and rolled back due to network bugs) to 2.0 .
Overall Linux is pretty damn good as a server OS, but I can certainly imagine someone finding and moving to a more stable system - though it'd probably be at the cost of ease of administration, speed of deploying services, etc.
File compression is also very important for backups, both for capacity and backup/restore speed. But you know what? In backups, you want to ensure that the archives are going to be recognisable and readable by as wide a variety of software as possible, so your disaster recovery options are open. Sure, you probably encrypt them, but there portable and fairly standard tools are also a good idea rather than some compression&archival app's built-in half-baked password protection.
As for compressing whole file systems, it doesn't work well because data compresses by variable amounts. It's hard to get a layout that handles this well - when a program overwrites a few blocks of a file, those blocks might grow and force everything to move, or force fragmentation of the file. That sort of thing. You might say to compress the data but store it in the original block layout - which works and solves the above problem, but loses you your performance gains because the drive will generally read a whole block if part of it is needed, so you have no net change. This doesn't mean that efficient read/write compressing file systems aren't possible, just that they are hard, and probably won't perform as well as you might initially expect. They'll also have very _different_ performance characteristics because of the changes required to make them work without insane levels of fragementation or lots of block copying.
Compressing file systems are amazing for backups, though, where files are written, read, or truncated, but rarely appended to or partially overwritten. I'd LOVE a widely supported r/w compressing FS for our backups here, but have to make do with compressed archives at the moment. Tape drives compress, but I don't have the cash for an SDLT here and we need that kind of capacity.
- The LWN data is pretty limited (being based on line deltas / number of commits) and a single sample... not really solid comparison material. Then again, I do cite it only as an example of a broader trend (Google being fairly active in kernel work).
- My assumptions about what they keep private are exactly that, but based on the fact that they do release more tech than most, and that it's in their interests to get useful things that aren't too critical or specialised merged. Doing so reduces their workload significantly, especially with core (non-FS/driver) changes, isn't bad techie PR, and lets them focus on any specialist stuff they *are* doing. It's speculation, but not baseless or wholly uninformed.
- AFAIK one of their more basic techs, the Google File System, is done in userspace anyway. Certainly most of their interesting work is.
Google submits a significant number of changes to the mainstream Linux tree, as shown by (among other things) this recent lwn.net article. For 2.6.20 they landed up rougly between Intel and HP... both of whom have much more reason to be working heavily on the kernel, especially on the server end of the market.
Of course, there's no way of knowing if they maintain whole new optimised subarches, special file system drivers, etc in-house... but I suspect that anything they do keep private is mostly not released because it won't be very useful outside Google. Perhaps they're limiting access to things that'd only be useful to their direct competition in immense data warehouses - but y'know what, I don't care myself. I wouldn't be surprised if the kernel folks would reject any excessively specialised or over-complex changes anyway.
That said, as you pointed out little of what they do is releases as OS. More than most companies (at some) - including some nice search and data handling tech and some handy libraries - but hardly the crown jewels. I for one do not find this overly troubling.
I do, however, share your spine-crawling feelings with regards to the DoubleClick association. I've never been fond of DoubleClick at the best of times, and don't like the thought of their data being combined with Google's.
Sure, it's detailed. Too bad the colour is still a poor match to human vision.
We see a huge dynamic range - we can see details in extremely dark areas and still perceive detail in very bright areas. What we see as bright or dark also depends on the surrounding lighting (and not just as your iris adapts, either, there are other effects at work). Even more importantly, our perception of colour intensity and brightness is not linear.
To get truly amazing video, we'd need to switch to exponential format colour that better matches how we actually see and can represent appropriately high dynamic ranges while still preserving detail. We'd also need to dynamically adapt the display to lighting conditions, so it matched our perceptual white-point & black point. Of course, we'd need to do this _without_ being confused by the light from the display its self. And, of course, we'd need panel technology capable of properly reproducing the amazing range of intensities involved without banding or loss of detail.
We're a very, very long way from video that's as good as it can get, as anyone in high quality desktop publishing, printing, photography or film can tell you. A few movie studios use production tools that go a long way in that direction and photographic tools are getting there too, but display tech is really rather inadequate, as are the colour formats in general use.
Unlike most special purpose new TLD proposals, this isn't immediately and obviously blatantly stupid.
It's limited in scope;
It has an access whitelist or admission requirements, rather than the usual definition of what's not admissable with the hope it'll politely stay away; and
It should be reasonably protected against spoofing in that most sites are already using SSL to (help) protect against MiTM attacks, DNS compromise, etc.
However, it may introduce a false sense of security when faced with a server compromise, client-side spoofing (URL bar replacement, etc) or client compromise (hooray for spyware!).
Nonetheless, this is about 1/0 times smarter than the.xxx TLD, the problems with which were astounding given the proposed "benefits" of it.
The upgrade seems smooth enough, though it's rougher than woody -> sarge was for me. Then again, I'm running much more complex systems now.
- squid may break if you use it for transparent proxying. It wants the "transparent" option after the listern directive(s) now to enable transproxying, but never used to.
- the xlibs upgrade does not go well if it can't remove everything in certain directories. In particular, having the jedit package installed screws this up badly. I had to do some manual fixing to get this working.
- Make really, really sure you have enough room in/var/backups when you upgrade slapd, or it'll require some hand fixing and a db4.2_recover.
- You'll probably want to use the maintainer's CUPS config, then re-configure it to your specs. The CUPS config has changed a lot and is not really compatible.
- cyrus delivery socket permissions may need resetting if you use cyrus & postfix.
Overall, though, for a system as complex as my servers, the process was largely fuss free.
Something like this could kind of work, but wow did they not get it right.
If they proposed a new alternate HTTP port (SSL mandatory) for content-controlled services, combined with an SSL certificate authority that only handed certs out to validated and approved hosts whose content had been examined, this could almost work. A CRL published by their "clean sites" CA could ensure that sites could be de-validated, causing users to get a warning from their browser when visiting the site or with simple browser configuration to be blocked from access entirely. Minor browser changes would be needed to support a different URL scheme ("boring:// " or whatever) to use the port/cert system - something MS could easily push out in Windows Update since it'd really just be a protocol alias for "https://domain.blah:someport" with a different trusted CA list and mandatory CRL checking. FF and Opera could also easily support it. A little bit of DNS abuse could introduce a convention like "connect to.clean domain sites on port 81 using SSL" as an uglier-but-more-idiot-proof alternative to a different URL schema.
Of course, instead they proposed to take over an existing service and push anything they don't like to "somewhere else" - without any consideration of how the hell this could ever work. Which, of course, it can't without completely redesigning the Internet... and even then they'd still need a whitelist or certification based system to control who gets access to their declared "clean" bit. Lets not get started on what's counted as "clean" once the creationists, scientologists, video-game-nazis, the completely humourless, etc get their hands on it. The only permitted content could soon be:
Why don't these twits find someone who understands the network and protocols to help them design something that might kinda half work? Oh, yeah... because they'd have to DO REAL WORK and SPEND MONEY to maintain a workable system since it'd require ongoing provider certification and content review with a whitelist-like inclusion model.
There's a spot down in there where the RIAA expert refers to IPV6, and this refers to 2004. That alone should get him laughed out of the tech community.
Why? I was using IPv6 in 2004. Admittedly, I was using it via 6to4 to allow three NATed networks to communicate seamlessly with all hosts within any of the networks - but using the multicast 6to4 gateway I also had access to the 6bone etc.
... goes and Rs TFA...
Oh. You're right - mixing up IPv6 and IPv4 like he did is indeed pretty damn sad for an "expert" on the stand. It looks like he just got muddled (at least, I _hope_ he knows the Internet runs largely on IPv4 not IPv6).
Australian TV broadcasters tend to keep only loosely to broadcasting schedules, so don't expect to be able to just watch one show. You'd best start ten minutes beforehand. And, of course, everything is on long delays as compared to the US, and often broadcast with weird gaps and sometimes even out of order.
Of course, they might just cancel the show if there's a football or cricket match on. Sure, they knew it'd be on weeks in advance, but they didn't bother planning for it.
To top things off, the ads are incessant and REALLY BAD. We're talking mind-bogglingly awful patronising badly-made crap.
So... why would anybody endure free to air TV in Australia? Until the Internet became a useful alternative, I just stopped watching it. Borrowed the odd DVD from friends, bought the odd DVD, watched more than the odd CD of AVIs, but that's about it - it just wasn't worth enduring the suck.
So, let me see - I could put up with that miserable crap, or I could otherwise obtain the show and get it:
when I want it (on time)
in better quality; and
ad free
I'd pay for HD downloads of shows - at decent prices and without that DRM crap. Unfortunately, most services don't provide access for Australians or are TV-like ("you'll watch what we want when we want you to"). They're also all DRM'd or at best streaming-only. The DRM is pointless, since the shows are ALREADY available on the 'net, so it deeply confuses me as to why they bother.
Sure, it's dodgy, but until the media industry is willing to move a bit and meet people in the middle, I'll continue to use the alternative means available.
Of course, all your new servers come with management cards that provide a VGA BIOS and a video card driver but send the frame buffer (and take keyboard/mouse I/O) over a management LAN anyway using RFB/ICA, right?
Right?
OK, so maybe you don't need those because your servers run command-line friendly operating systems, which will have an IPMIv2 daughterboard on the motherboard IPMI interface to enable remote power control, serial-console-over-LAN, etc. Right?
There are some situations in which CFLs are unsuitable. In particular, colour workflows demand balanced-spectrum environmental lighting that neither CFLs nor conventional incandescent lights provide. Banning incandescents doesn't much bother me, but room must be allowed for specialized lighting needs.
Well, so long as you want your magazines, newspapers, films, etc to look good.
Wow, thanks for the tip. I'd heard of those drivers but just assumed they were tweaker/overclocker stuff likely to lead to stability problems. To my astonishment they install and work fine on this machine, and don't even muck up the power management.
I still won't buy Acer ever again, of course, when people like Dell make better machines with better support (friend of mine has an XPS. Big and ugly but otherwise amazing)... but having a workaround for the driver issue is nice.
Yep. It's not even that bad, though, if they release updates to their supported hardware when ATi puts out a new drivers. Unfortunately they neither do so nor acknowledge that there might be any reason why they should.
Not only will they usually refuse to sell parts, but they don't provide driver updates to things like the onboard ATi video (and you can't get them straight from ATi because Acer modify the parts). As far as they're concerned if the old drivers passed QA at hardware release time they're perfect and any updates for any reason are unnecessary.
*gag*
Same with the other hardware on their machines, but most of that can be found on the chipset mfgr's sites with enough work.
Thanks for your very interesting comment. I'll have to do some digging myself, as I realised that I don't in fact have specific examples... and need to confirm that they do exist. While I acknowledged that the threat of such lawsuits are often just an excuse to do what the board want to anyway, I've claimed that there are real cases too, and should've had the evidence on hand to back that up.
Spurious lawsuits can be a proplem, as you pointed out. I find it interesting that some US states have some level of protection against such (eg the SEC rules), which is good to see.
It'd be interesting to find out how much of this is excuses by management to justify what they want to do anyway, how much is misinformation, and how much is legit. Time to do some digging...
Charters can be changed at any time... if and only if you can get your shareholders to agree to it. It's quite likely you'll have to buy back a lot of shares to get a vote to pass. Starting out with a charter written to suit your goals avoids that problem.
What would the charter restrict anyway?
Most importantly, it'd need to expand the definition of shareholder responsibility to allow for ethical behaviour and social responsibility to protect directors against lawsuits by shareholders unhappy that the chance to eke another cent out of someone though unethical behaviour has been passed up. One of the bigger problems with a company whose directors want to do "the right thing" is being prevented from doing so by the threat of shareholder lawsuits. Sometimes. Often, of course, the directors are as bad or worse, and on the whole shareholders seem to be getting a bit brighter (note the recent appearance of environmental impact statements, "triple bottom line" info etc in company reports due to shareholder demand, for example). Still, making it clear that the directors can't be sued for passing up profit in favour of ethical behaviour isn't a bad idea.
It's definitely true that such a move can limit some competititive choices. That's hard. It'd be nice to believe that it'd be made up for by people preferring the more clearly ethical organisation, but more often than not people seem to talk big, then turn a blind eye when they see that the other product is two bucks more expensive. This is a hard problem, and it does limit what a company can do. That said, there's going to be some payoff from a properly spun "ethical company" operation (a real one, not, eg, Body Shop... who tried, but failed to protect against shareholders), and that might just be enough. Staff turnover is expensive too, and a company that doesn't force too many ethically questionable things on a person may well find they keep people better. I'd like to see some evidence for/against that, as it's just a suspicion on my part, but one I hope is true (certainly it applies to me).
You make the assumption here that a company must "protect shareholder value" (ie profiteer in an amoral manner) and "expand the market for the product".
That's true of most public companies. However, it's quite possible to write a corporate charter that limits such things, introducing issues of social responsibility and ethical behaviour. You just need to do it early and make potential shareholders aware of the rules. Few people are willing to do this, since it removes their excuse to profiteer in the name of the company, and makes it harder to get venture funding. But you know what? It's quite possible. And that's just for public companies - if you run a private company, none of this applies, and it's your ethics as the owner/partner that matters.
So... what you're talking about isn't making RMS somehow face the real world (something that's probably not the worst idea in the world) but also to do so in a situation contrary to his if nothing else strongly held ethical framework and values. Not going to work, and it doesn't mean he just can't face the real world. Heck, there are companies I'd refuse to work for on basic ethical grounds, though I'm far from as strident as RMS, nor do I focus on the same things.
I guess my point is that you seem to equate "company" with "traditional large corporation with uncontrolled shareholder-driven amoral profiteering"... somthing I just can't accept.
Your answers struck me as pretty reasonable. I suspect some folks here just find it hard to imagine that a genuine, if diplomatically worded, answer from anybody representing a company can be their own answer.
Sorry for the rude idiots here. They're loud but they're not everybody.
The current Eiffel compilers essentially convert pre- and post- condition sections to assertions. Faults are not detected until runtime when that code is excersised. A comprehensive test suite with full code coverage is necessary.
In other words, they don't do anything better than assertions used according to suitable conventions - except look prettier.
I'm not sure what you're getting at with respect to "a million cryptic asserts all over the place (which will perforce be bound to your implementation rather than the point of contracts which is that they bind to the interface)" - in that assertions used as interface contact checking will be present only at interface entry and exit points (like contract blocks) and no more cryptic than contract block entries, which they're logically equivalent to. I'd _prefer_ them in contract blocks, but with something as simple as a standard comment to deliniate where they begin and end it's not a big issue.
Now, if Eiffel compilers started doing some static analysis to validate interfaces at compile time then I might care, because there's something I can benefit from that I _can't_ get from well used and documented assertions. The advantage of using contract blocks might be that while Eiffel compilers can't do this now, theoretically they might in the future. On the other hand, I'd have to endure a more limited set of available libraries, the irritation of talking to C++ code via C adapter interfaces, and quite a bit more besides for a benefit that may never arrive.
I'll stick with my test suite (which I'll need anyway) and careful documented use of assertions to check the interface behaviour, I think.
Slashdot Mirror
Flash isn't perfect under Linux, but it does work pretty well. It used to be nightmarish when it when through its long unmaintained-for-Linux phase, but for a couple of years now it's been pretty solid on mainstream distros.
There can be problems if you use anything unusual, or run a 64-bit native system.
That said, I have Flash installed in Firefox on my X11 thin clients at work with no issues beyond what you'd expect when combining software written by idiots (most flash movies) with low graphical performance hosts (X11 thin clients). The worst issue I see is that it can slow down the client a bit when playing animations created by "designers" who think everyone's using a Core 2 Duo machine with a high performance 3D accelerated video card. Usually ads.
Even then, nothing crashes and at worst the browser tab/session can be closed. The flashblock extension has made life a little nicer though by letting the users choose whether they want to view flash, rather than being forced into viewing lots of badly-written flash ad movies as they try to get real work done. I find the same thing to be necessary on my Core 2 Duo WinXP laptop.
In short - recent Flash versions are pretty darn good.
Thanks for the tips.
I use hard mounts (the default) but have not been setting the `intr' flag. However, if a process always hangs when accessing a file that doesn't help - whether the process is unkillable, or just can't run, if the user's session depends on it the user's still down for the count.
I force NFS version 3 and sync mode (because these are rw shares).
The worst problem I've had is with home directories, but even now that I export a logical volume to the Xen guest for home dirs instead, I still have other NFS related issues. Hopefully they'll improve over time, but it's pretty frustrating for such an old and core service. Maybe the NFSv4 work will help clean up and improve the Linux NFS implementation.
CIFS with posix extensions does look promising. I find this depressing given how awful the CIFS protocol is... but if it works, it works.
Anyhow, thanks for the tips. I'll set the intr option, and I think I'll actually switch to soft mounts so I can force a disconnect when the NFS session goes brain dead.
I've been pretty happy with Linux in general, but I'm not thrilled with its network file system support. In particular, NFS has been prone to occasionally leave a particular file in a state where any process that tries to access it hangs in the kernel, and only a system reboot (!) fixes the problem. I'm hoping this was fixed between 2.6.10 and 2.6.20, which I've just upgraded our systems to.
Xen is also less solid than I'd like, at least on the dual Xeon server board I'm running it on. I've had a couple of bizarre issues with Xen 3.0 now that make me wonder if I should go back (again - I tried an older 3.0 before and rolled back due to network bugs) to 2.0 .
Overall Linux is pretty damn good as a server OS, but I can certainly imagine someone finding and moving to a more stable system - though it'd probably be at the cost of ease of administration, speed of deploying services, etc.
We have this thing commonly known as "dry ice" ; otherwise as "carbon dioxide ice". They don't mine it, you know.
It comes from AIR. *gasp*. It's also been around for a very long time.
File compression is also very important for backups, both for capacity and backup/restore speed. But you know what? In backups, you want to ensure that the archives are going to be recognisable and readable by as wide a variety of software as possible, so your disaster recovery options are open. Sure, you probably encrypt them, but there portable and fairly standard tools are also a good idea rather than some compression&archival app's built-in half-baked password protection.
As for compressing whole file systems, it doesn't work well because data compresses by variable amounts. It's hard to get a layout that handles this well - when a program overwrites a few blocks of a file, those blocks might grow and force everything to move, or force fragmentation of the file. That sort of thing. You might say to compress the data but store it in the original block layout - which works and solves the above problem, but loses you your performance gains because the drive will generally read a whole block if part of it is needed, so you have no net change. This doesn't mean that efficient read/write compressing file systems aren't possible, just that they are hard, and probably won't perform as well as you might initially expect. They'll also have very _different_ performance characteristics because of the changes required to make them work without insane levels of fragementation or lots of block copying.
Compressing file systems are amazing for backups, though, where files are written, read, or truncated, but rarely appended to or partially overwritten. I'd LOVE a widely supported r/w compressing FS for our backups here, but have to make do with compressed archives at the moment. Tape drives compress, but I don't have the cash for an SDLT here and we need that kind of capacity.
I should however note that:
... not really solid comparison material. Then again, I do cite it only as an example of a broader trend (Google being fairly active in kernel work).
- The LWN data is pretty limited (being based on line deltas / number of commits) and a single sample
- My assumptions about what they keep private are exactly that, but based on the fact that they do release more tech than most, and that it's in their interests to get useful things that aren't too critical or specialised merged. Doing so reduces their workload significantly, especially with core (non-FS/driver) changes, isn't bad techie PR, and lets them focus on any specialist stuff they *are* doing. It's speculation, but not baseless or wholly uninformed.
- AFAIK one of their more basic techs, the Google File System, is done in userspace anyway. Certainly most of their interesting work is.
Google submits a significant number of changes to the mainstream Linux tree, as shown by (among other things) this recent lwn.net article. For 2.6.20 they landed up rougly between Intel and HP ... both of whom have much more reason to be working heavily on the kernel, especially on the server end of the market.
Of course, there's no way of knowing if they maintain whole new optimised subarches, special file system drivers, etc in-house... but I suspect that anything they do keep private is mostly not released because it won't be very useful outside Google. Perhaps they're limiting access to things that'd only be useful to their direct competition in immense data warehouses - but y'know what, I don't care myself. I wouldn't be surprised if the kernel folks would reject any excessively specialised or over-complex changes anyway.
That said, as you pointed out little of what they do is releases as OS. More than most companies (at some) - including some nice search and data handling tech and some handy libraries - but hardly the crown jewels. I for one do not find this overly troubling.
I do, however, share your spine-crawling feelings with regards to the DoubleClick association. I've never been fond of DoubleClick at the best of times, and don't like the thought of their data being combined with Google's.
slosh
fizz!
Aah... not only have we saved ALL of our VAX power bill, but we've eliminated all noise in the process.
Now to persuade the Boss to dive in to look for the drain plug...
Sure, it's detailed. Too bad the colour is still a poor match to human vision.
We see a huge dynamic range - we can see details in extremely dark areas and still perceive detail in very bright areas. What we see as bright or dark also depends on the surrounding lighting (and not just as your iris adapts, either, there are other effects at work). Even more importantly, our perception of colour intensity and brightness is not linear.
To get truly amazing video, we'd need to switch to exponential format colour that better matches how we actually see and can represent appropriately high dynamic ranges while still preserving detail. We'd also need to dynamically adapt the display to lighting conditions, so it matched our perceptual white-point & black point. Of course, we'd need to do this _without_ being confused by the light from the display its self. And, of course, we'd need panel technology capable of properly reproducing the amazing range of intensities involved without banding or loss of detail.
We're a very, very long way from video that's as good as it can get, as anyone in high quality desktop publishing, printing, photography or film can tell you. A few movie studios use production tools that go a long way in that direction and photographic tools are getting there too, but display tech is really rather inadequate, as are the colour formats in general use.
I call marketing BS.
Unlike most special purpose new TLD proposals, this isn't immediately and obviously blatantly stupid.
However, it may introduce a false sense of security when faced with a server compromise, client-side spoofing (URL bar replacement, etc) or client compromise (hooray for spyware!).
Nonetheless, this is about 1/0 times smarter than the .xxx TLD, the problems with which were astounding given the proposed "benefits" of it.
The upgrade seems smooth enough, though it's rougher than woody -> sarge was for me. Then again, I'm running much more complex systems now.
/var/backups when you upgrade slapd, or it'll require some hand fixing and a db4.2_recover.
- squid may break if you use it for transparent proxying. It wants the "transparent" option after the listern directive(s) now to enable transproxying, but never used to.
- the xlibs upgrade does not go well if it can't remove everything in certain directories. In particular, having the jedit package installed screws this up badly. I had to do some manual fixing to get this working.
- Make really, really sure you have enough room in
- You'll probably want to use the maintainer's CUPS config, then re-configure it to your specs. The CUPS config has changed a lot and is not really compatible.
- cyrus delivery socket permissions may need resetting if you use cyrus & postfix.
Overall, though, for a system as complex as my servers, the process was largely fuss free.
Did you see the "budget" section? I wish I fit that, but the truth is ... not so much.
Something like this could kind of work, but wow did they not get it right.
.clean domain sites on port 81 using SSL" as an uglier-but-more-idiot-proof alternative to a different URL schema.
... and even then they'd still need a whitelist or certification based system to control who gets access to their declared "clean" bit. Lets not get started on what's counted as "clean" once the creationists, scientologists, video-game-nazis, the completely humourless, etc get their hands on it. The only permitted content could soon be:
... because they'd have to DO REAL WORK and SPEND MONEY to maintain a workable system since it'd require ongoing provider certification and content review with a whitelist-like inclusion model.
If they proposed a new alternate HTTP port (SSL mandatory) for content-controlled services, combined with an SSL certificate authority that only handed certs out to validated and approved hosts whose content had been examined, this could almost work. A CRL published by their "clean sites" CA could ensure that sites could be de-validated, causing users to get a warning from their browser when visiting the site or with simple browser configuration to be blocked from access entirely. Minor browser changes would be needed to support a different URL scheme ("boring:// " or whatever) to use the port/cert system - something MS could easily push out in Windows Update since it'd really just be a protocol alias for "https://domain.blah:someport" with a different trusted CA list and mandatory CRL checking. FF and Opera could also easily support it. A little bit of DNS abuse could introduce a convention like "connect to
Of course, instead they proposed to take over an existing service and push anything they don't like to "somewhere else" - without any consideration of how the hell this could ever work. Which, of course, it can't without completely redesigning the Internet
<html>
<head><title>Blank</title></head>
<body>
</body>
</html>
Why don't these twits find someone who understands the network and protocols to help them design something that might kinda half work? Oh, yeah
Why? I was using IPv6 in 2004. Admittedly, I was using it via 6to4 to allow three NATed networks to communicate seamlessly with all hosts within any of the networks - but using the multicast 6to4 gateway I also had access to the 6bone etc.
Oh. You're right - mixing up IPv6 and IPv4 like he did is indeed pretty damn sad for an "expert" on the stand. It looks like he just got muddled (at least, I _hope_ he knows the Internet runs largely on IPv4 not IPv6).
Australian TV broadcasters tend to keep only loosely to broadcasting schedules, so don't expect to be able to just watch one show. You'd best start ten minutes beforehand. And, of course, everything is on long delays as compared to the US, and often broadcast with weird gaps and sometimes even out of order.
Of course, they might just cancel the show if there's a football or cricket match on. Sure, they knew it'd be on weeks in advance, but they didn't bother planning for it.
To top things off, the ads are incessant and REALLY BAD. We're talking mind-bogglingly awful patronising badly-made crap.
So ... why would anybody endure free to air TV in Australia? Until the Internet became a useful alternative, I just stopped watching it. Borrowed the odd DVD from friends, bought the odd DVD, watched more than the odd CD of AVIs, but that's about it - it just wasn't worth enduring the suck.
So, let me see - I could put up with that miserable crap, or I could otherwise obtain the show and get it:
I'd pay for HD downloads of shows - at decent prices and without that DRM crap. Unfortunately, most services don't provide access for Australians or are TV-like ("you'll watch what we want when we want you to"). They're also all DRM'd or at best streaming-only. The DRM is pointless, since the shows are ALREADY available on the 'net, so it deeply confuses me as to why they bother.
Sure, it's dodgy, but until the media industry is willing to move a bit and meet people in the middle, I'll continue to use the alternative means available.
Of course, all your new servers come with management cards that provide a VGA BIOS and a video card driver but send the frame buffer (and take keyboard/mouse I/O) over a management LAN anyway using RFB/ICA, right?
Right?
OK, so maybe you don't need those because your servers run command-line friendly operating systems, which will have an IPMIv2 daughterboard on the motherboard IPMI interface to enable remote power control, serial-console-over-LAN, etc. Right?
Right?
*sigh*. I'll go get my keyboard and VGA cable.
There are some situations in which CFLs are unsuitable. In particular, colour workflows demand balanced-spectrum environmental lighting that neither CFLs nor conventional incandescent lights provide. Banning incandescents doesn't much bother me, but room must be allowed for specialized lighting needs.
Well, so long as you want your magazines, newspapers, films, etc to look good.
Wow, thanks for the tip. I'd heard of those drivers but just assumed they were tweaker/overclocker stuff likely to lead to stability problems. To my astonishment they install and work fine on this machine, and don't even muck up the power management.
I still won't buy Acer ever again, of course, when people like Dell make better machines with better support (friend of mine has an XPS. Big and ugly but otherwise amazing)... but having a workaround for the driver issue is nice.
Yep. It's not even that bad, though, if they release updates to their supported hardware when ATi puts out a new drivers. Unfortunately they neither do so nor acknowledge that there might be any reason why they should.
Not only will they usually refuse to sell parts, but they don't provide driver updates to things like the onboard ATi video (and you can't get them straight from ATi because Acer modify the parts). As far as they're concerned if the old drivers passed QA at hardware release time they're perfect and any updates for any reason are unnecessary.
*gag*
Same with the other hardware on their machines, but most of that can be found on the chipset mfgr's sites with enough work.
Thanks for your very interesting comment. I'll have to do some digging myself, as I realised that I don't in fact have specific examples ... and need to confirm that they do exist. While I acknowledged that the threat of such lawsuits are often just an excuse to do what the board want to anyway, I've claimed that there are real cases too, and should've had the evidence on hand to back that up.
Spurious lawsuits can be a proplem, as you pointed out. I find it interesting that some US states have some level of protection against such (eg the SEC rules), which is good to see.
It'd be interesting to find out how much of this is excuses by management to justify what they want to do anyway, how much is misinformation, and how much is legit. Time to do some digging...
Charters can be changed at any time ... if and only if you can get your shareholders to agree to it. It's quite likely you'll have to buy back a lot of shares to get a vote to pass. Starting out with a charter written to suit your goals avoids that problem.
What would the charter restrict anyway?
Most importantly, it'd need to expand the definition of shareholder responsibility to allow for ethical behaviour and social responsibility to protect directors against lawsuits by shareholders unhappy that the chance to eke another cent out of someone though unethical behaviour has been passed up. One of the bigger problems with a company whose directors want to do "the right thing" is being prevented from doing so by the threat of shareholder lawsuits. Sometimes. Often, of course, the directors are as bad or worse, and on the whole shareholders seem to be getting a bit brighter (note the recent appearance of environmental impact statements, "triple bottom line" info etc in company reports due to shareholder demand, for example). Still, making it clear that the directors can't be sued for passing up profit in favour of ethical behaviour isn't a bad idea.
It's definitely true that such a move can limit some competititive choices. That's hard. It'd be nice to believe that it'd be made up for by people preferring the more clearly ethical organisation, but more often than not people seem to talk big, then turn a blind eye when they see that the other product is two bucks more expensive. This is a hard problem, and it does limit what a company can do. That said, there's going to be some payoff from a properly spun "ethical company" operation (a real one, not, eg, Body Shop... who tried, but failed to protect against shareholders), and that might just be enough. Staff turnover is expensive too, and a company that doesn't force too many ethically questionable things on a person may well find they keep people better. I'd like to see some evidence for/against that, as it's just a suspicion on my part, but one I hope is true (certainly it applies to me).
You make the assumption here that a company must "protect shareholder value" (ie profiteer in an amoral manner) and "expand the market for the product".
... what you're talking about isn't making RMS somehow face the real world (something that's probably not the worst idea in the world) but also to do so in a situation contrary to his if nothing else strongly held ethical framework and values. Not going to work, and it doesn't mean he just can't face the real world. Heck, there are companies I'd refuse to work for on basic ethical grounds, though I'm far from as strident as RMS, nor do I focus on the same things.
That's true of most public companies. However, it's quite possible to write a corporate charter that limits such things, introducing issues of social responsibility and ethical behaviour. You just need to do it early and make potential shareholders aware of the rules. Few people are willing to do this, since it removes their excuse to profiteer in the name of the company, and makes it harder to get venture funding. But you know what? It's quite possible. And that's just for public companies - if you run a private company, none of this applies, and it's your ethics as the owner/partner that matters.
So
I guess my point is that you seem to equate "company" with "traditional large corporation with uncontrolled shareholder-driven amoral profiteering"... somthing I just can't accept.
Your answers struck me as pretty reasonable. I suspect some folks here just find it hard to imagine that a genuine, if diplomatically worded, answer from anybody representing a company can be their own answer.
Sorry for the rude idiots here. They're loud but they're not everybody.
That's exactly the point.
The current Eiffel compilers essentially convert pre- and post- condition sections to assertions. Faults are not detected until runtime when that code is excersised. A comprehensive test suite with full code coverage is necessary.
In other words, they don't do anything better than assertions used according to suitable conventions - except look prettier.
I'm not sure what you're getting at with respect to "a million cryptic asserts all over the place (which will perforce be bound to your implementation rather than the point of contracts which is that they bind to the interface)" - in that assertions used as interface contact checking will be present only at interface entry and exit points (like contract blocks) and no more cryptic than contract block entries, which they're logically equivalent to. I'd _prefer_ them in contract blocks, but with something as simple as a standard comment to deliniate where they begin and end it's not a big issue.
Now, if Eiffel compilers started doing some static analysis to validate interfaces at compile time then I might care, because there's something I can benefit from that I _can't_ get from well used and documented assertions. The advantage of using contract blocks might be that while Eiffel compilers can't do this now, theoretically they might in the future. On the other hand, I'd have to endure a more limited set of available libraries, the irritation of talking to C++ code via C adapter interfaces, and quite a bit more besides for a benefit that may never arrive.
I'll stick with my test suite (which I'll need anyway) and careful documented use of assertions to check the interface behaviour, I think.
--
Craig Ringer