In case you haven't been over to w3.org in a while, the HTML/XHTML standards are approaching the layout capabilities of FrameMaker. They're up against the Gecko engine, and the larger trend of dead-tree going out of style. Not that paper is dead, but you will probably skim electronic versions of anything before you want to carry around the paper version. There is additional energy cost associated with publishing on paper, and the cost of energy threatens to climb to 1973 levels. Electronic media reduces our dependance on fossil fuels for communication and information transfer.
I would guess this is news that Adobe FrameMaker is in "sunset mode." With Gimp coming up on PhotoShop's heels, the crops of Adobe bigots (the real value of the company) coming out of college may be in decline. Thus, Adobe may be in decline in a broader scope. Maybe they are going out quitely, and maybe they are circling the wagons. I'm sure there are hurt feelings regarding the iPhoto flap. The problem is: the only strategy Adobe has in fighting Apple is to lose.
Maybe Adobe is gearing up for a last-hurrah rewrite of the be-all end-all multimedia production suite? Then again, isn't multimedia so 1990s?
That said, I think the real issue is the middle-men you mentioned. Artists (like myself) are very much aware that the major labels have nothing to offer anymore, and that the future, somehow, lies online. I want to know how we could revise the copyright laws to continue to protect artists, but at the same time allow for Internet users to have widespread access to music (thereby increasing their popularity and hopefully their bank account).
So, do you think you could sell "tickets" for downloading your music if you had a good enough demo/promo available for free? You could hang it out there on the web like a charity pledge drive with the thermometer counting up tickets sold. Meanwhile, you can keep working behind the scenes, leaking out some promo material to show how you've been working.
A) My "ticket" suggestion precludes assuming you need any certain amount of sales to break even. Instead of raising the revenue requirements and the risk, lower the production cost until it meets a comfortable risk level.
B) Regarding your #1: You don't have to wait 5 years. You are one person. Everyone can decide how long they want to wait. Its another free-market decided issue.
C) Regarding your #2: If you can wait a few years to get it, then the artist has not done a very good job at making a compelling piece of art/promo. If you can wait that long, maybe you're not a reliable source of revenue. I don't think you're much of a factor except you will probably buy some other competing stuff instead.
Maybe the author of this hypothetical book can write a foreword and then ue that to sell tickets for the book before he writes it or after he writes it but before he releases it to anyone. Think of how movies are marketed with trailers before they are finished.
It doesn't matter how long it takes the artist to produce the work. Maybe the work can be released in iterations like chapters or scenes. Maybe you will have to actually earn people's respect for your creative abilities before you ask them all to fund a big project. It should be easier for an artist/author to get *some* money from a lot of regular joes than it is to get a lot of money from a few producers/publishers.
It used to be hard to make intellectual property that was compelling enough to justify the enormous cost of distribution. Since the distribution costs and production costs forced each other up, there was a lot of sunk-cost to deal with before any customers even had the option of paying for the product. Now, distribution costs are so low that you can do as little or as much production as you want, and you can distribute it nearly for free if you use peer-to-peer distribution networks. Software like Apple's iLife suite lowers the ante on production costs to within reach of nearly any high school or college student, let alone professionals moonlighting as film or recording artists.
Maybe most of the product will not be that good, but there is still no reason to involve the massive and massive expense of a full-blown 1980s style music or film production. For example, people routinely pay for concert tickets (guaranteed delivery) of a performance--sight unseen. If too few tickets are sold, the show is cancelled, and the ticket holders are refunded. Why not sell download tickets for yet unfinished films and albums? Then the fan base can directly fund proven popular artists' productions.
I recognise that some artists and a lot of middlemen enjoy lots of residual income from past production work. Why is it so hard to recognise that this is not the only way to pay artists for their work, and there may be better ways if we think about it? The way I see it, copyrights only protect residual income, which pays artists and middlemen to NOT produce new material. Why do people think this is good?
This is not surprising. It is only controversial because some people desperately *want* to believe that Microsoft is good. This is a juvenile reaction to the bad-mouthing that Microsoft gets. This constant bashing is in bad taste, but whether it is fair or not will be borne out entirely by the facts that are unfolding before our very eyes.
The problem with Microsoft and all of their drone customers is that the relationship is not mutually beneficial. It seems so, however, to the dupes who take the terms that the vendor pitches them. The problem with bashing the house-of-cards is all of the hurt feelings involved with people who realize it too late.
So, try not to say anything bad about Microsoft. Just be compassionate towards the people who are suffering. Try to help people realise how much they are sharing the pain with others... no wait... you'll just end up saying the same things that piss off the Microsoft drones. On second thought, just keep a CDROM on hand with something better to install, and give it to the tortured drones with a smile and your head cocked slightly to one side (AOL style). Don't say a word. It isn't necessary or even helpful.
You show up to work every day and take the paycheck even though you KNOW what you are bing told to do is BAD AND WRONG.
Tell me again mister hypothetical "good" Microsoft developer: why should you be excused from ethical responsibility? The devil made you do it? Hrm?
Let me tell you that I am not impressed with this crap. Does anyone remember Mac HFS file format used to do "resource forks" to contain extensible metadata on files. The Finder would know, for instance, that the last time you opened a particular file, a particular progam was used to save it. The default action for that file if you double-clicked the icon was to open it with the last-saver application. The problem isn't getting the metadata out there. Been there; done that, for years. The problem is indexing all of it. What? Are you going to put a Google style cross-correlation engine on your PC to grind through the FS metadata indexes every time you change a file? How do you tell which metadata is worth all of the effort? The worst case workload increases geometrically with the number of files and the kind of metadata.
What about BeFS? It took this problem on and made demonstrable progress. If you searched your filesystem with find(1), you would match MP3s by artist name.
The problem is, Microsoft's department of predation^H^H^H^H^H^H^H^H^Hinnovation is looking at these two ideas and asking the question, "How can we use this to squeeze a few more dimes out of our captive market?" They want blood, and it is the very personal connections between the rich collection of data on your hard drive, and how you personally relate it to your life. While they try to convince you what it would be worth to you, ask yourself what it's worth to them!
The first thing I see is the suggestion that there should be a "contacts" file type built into the OS to handle all of your contact data. Maybe this should be validated against a master database in Redmond? Maybe they are just aching for the warm feeling they get from that good-old lock-in of captive data and the phantom control it gives them over ISVs.
Can anyone else think of any nasty easter eggs we all might find in WinFS (besides the poo-poo'ing that they gave metadata sharing/privacy choice)?
You see, the federal government has a constitutional, and historical jurisdiction over interstate commerce. If it gets to a turf war, then NO states will be able to levy excise taxes on interstate commerce, or (more likely) states will be required to adhere to the US Dept. of Commerce rules. That will allow federal officials like the US. President from having to commit political self-injury of imposing a new, unpopular federal Internet sales tax.
To understand this issue you must understand the role government plays in protecting and fostering and regulating commerce on all levels--not just sales. If disputes arise over the sale, which state will adjudicate the dispute? Now the State of Kansas has a tax-revenue interest in making their consumers^H^H^H^H^H^H^H^H^Hcitizens available for e-commercial harvest by the corporations who can $$$$ lobby their smalltime statehouse officers.
Maybe I mushed this up a bit. I remember vaguely that after the USDoJ got the findings of fact, several states sued for damages based on them. I remember at least one of them gave credit to Microsoft for copies of Microsoft products donated to schools, etc. That gets my hackles up.
In the US, the courts found that in fact, Microsoft had violated the Sherman Antitrust Act, ruling just short of a "guilty" verdict that no more arguments on facts of the case would mitigate a guilty verdict. The Sherman act is not civil law. It is criminal law. At this point, Microsoft shifted from a not-guilty stance, to negotiating a settlement with the USDoJ. The courts waited patiently. They dragged it out as long as they could, and ultimately got a monopoly-friendly US President in charge of the USDoJ to relax the pressure. The kids are now guarding the cookie jar.
Microsoft is not really a technology company. They are an Intellectual Property (IP) law firm trying to maintain IP assets. They will fight like dogs. That's what they do. They are dogs.
I am begging any europeans reading this to make a holy noise about "COUPONS FOR MICROSOFT PRODUCTS WILL NOT BE ACCEPTED IN LIEU OF CASH".
It's bad enough that we have Jethro Clampett in the US presidency, in charge of the USDoJ and the people's interest in the MS antitrust issue. Please help make sure the goon's mistakes are not mirrored in the EU! Also, don't accept any namby-pamby payment plans. Get the lump-sum immediately, or seize assets and slap extra fines for delaying payment.
What I'm whining about is mount_mfs. You used to be able to add a/tmp or/var/run filesystem to fstab with a "mfs" type and the "-s256M,2,0" in the mount options, and thus get it to mount up along with/usr and/var before any userland software starts using/tmp or/var/run.
There isn't (the last time I checked) a clean way to do that in 5.0, and I have the prejudice that it should be part of the default install. If you want a persistent/tmp or/var/run, then it should be your special config, IMHO.
I run FreeBSD 5.x as a desktop machine, and I don't find it lacking. Small things get my goat like 5.0 taking away the ability to mount a MFS/tmp out of/etc/vfstab, and having to hack it into the rc scripts, and having to REDO it every time you upgrade...
One of the biggest piles of bullshit is all the Linux developers who can't write cross-platform code. They get all sloppy with introducing Linux dependencies when it isn't really necessary, and then someone like me has to beat on it mercilessly to get it to configure or compile on FreeBSD. Then people say "FreeBSD is behind on the desktop because it doesn't have BLAH latest BLAH." The cloud of flies on the bullshit comes from people saying that it is too hard to use the Ports tree when they want some software BLAH or blatently disregarding the fact that NVIDIA GLX DRIVERS work just fine and saying you need that for BLAH game.
The implicit assumption that FreeBSD should support KDE's buggy cross-platform-problem apps instead of the other way around makes me sigh.
Linux distributrions are very very duct-tape and drywall screws holding things together. I'm not so familliar with FreeBSD 5.x yet, but 4.x and 3.x and 2.x were all very easy to read. If source code is really important to you, you will be able to confirm this by reading the stuff. I disagree with all the "integrated feel" arguments as they are highly subjective and vague.
The bottom line is, Linux is definitely better for root lusers because too much software is written for dirty Linux users who run gnome-session as root. FreeBSD requires some ingenuity or effort that these developers could not be bothered to exercise. However, lets say that the forward-thinking design principles of the FreeBSD project keep old servers humming along for years while sysadmins can say "I guess someday I should upgrade that server," and never really get around to it.
Read the article on the process scheduler to see why you might prefer to suffer the pangs of debugging sloppy Linux software to get a FreeBSD desktop system up and running.
The goofiest thing is that if you want to run Darwin without the Quartz Window Manager and MacOS X GUI, you can run XDarwin and get essentially what you would get running a PPC build of FreeBSD 4.x on Apple hardware.
Some things give me grief, but I prefer Jaguar and even moreso Panther to Gnome and KDE and WindowMaker and AfterStep and FVWM2. Little things get me like having Terminal.app windows stacked so that the man page is under the top window with just enough transparency to read the obscure command options while I tweak the script in the top window's vi. Even a year later, I catch myself thinking "Nice!"
Specifically, I tested my own sparcv9 OpenSSH on sparcv9 OpenSSL compiled with GCC-3.2.1. I got different results, and I have a different conclusion. My needs are to scp 8GB database dumps from one host to several others. I was interested in two factors. First, if run time was significantly different, that would be a compelling factor. That factor accounts for economy in scarce maintenance window time which I can safely saturate the network. Second, I was interested in the amount of system resources consumed during the process.
My results were different from the OSNews guy, but then again I am not intimidated by gcc make bootstrap. My sparcv9 OpenSSL libcrypto was carefully configured and compiled to use as much of the sparcv9 assembly code as the OpenSSL project provided. Both of my hosts were Sun Fire V880s with 4x750MHz Ultrasparc-III CPUs running 64 bit Solaris 8. SSH was configured to use the Blowfish symmetric cipher because it is not as CPU expensive as 3DES or AES in software. The disk volumes of the source and sink were EMC Symmetrix volumes over 1Gbps FC SAN using Emulex 900x host adapters. Over several trials, neither 64 nor 32 bit SSH could claim a run time advantage. However, the user-CPU time (number of cpu cycles spent executing SSH code as opposed to time spent waiting for IO service times or kernel/syscalls to complete) for the Sparcv9 SSH was slightly more than half of the same statistic for the Sparcv7 binary.
Admittedly, there is a difference in my benchmark test cases aside from instruction or data word length. Sparcv7 has no integer multiply or integer divide instructions, so it must rely on long-division and repeated adding to achieve the results of those operations. I needed a sparcv7 binary because I still have one old sparcv7 box in service that needs SSH. Because of the cache hit ratio when doing that kind of math, and the fact that Blowfish does not rely heavily on those operations, I doubt that these instructions would account for the difference in CPU cycles required to process this 8GB file.
Confirming this is difficult because the sparcv8 ABI was a 32 to 64bit crossover architecture in which the OS would interperet and optimize some operations if they were running on a 64 bit Solaris (2.7 or 8) kernel. Thus, a 32 bit sparcv7 binary running on sparcv9 hardware and a sparcv9 kernel may actually be partially executed in 64 bit mode, and be efficient at it. If there are any sparc ABI guru comments to enlighten us on the specifics, those comments would be appreciated. I believe a more rigorous test would verify that the kernel running the 32 bit userland software was a 32 bit kernel.
I conclude that the large data word size allowed SSH to encrypt the 8GB file in nearly 50% fewer CPU cycles, and therefore is faster for this type of operation. Aside from that, note that RSA/DSA operations on the sparcv7 binaries are SIGNIFICANTLY slower, probably due to the multiplication and division required by those algorithms. I'm sorry I wasn't doing this benchmark for publication or I would have saved my data/results.
My sentiments exactly. Moreover, how is this going to kill iPods? Its just the competition we need to get more from either Apple or Microsoft. Bring it on! I have a 5GB first generation iPod, and it still rules. If replacement hard drives were available at larger sizes, I wouldn't even think of letting it go. iTunes smart lists are making it easier to stretch the 5GB since my CD collection is over 10GB at 160bps MP3 compression. It is a significant part of my lifestyle now, but its going to take a lot to make me give it up. Something better? How much?
Where I work, they license and use Citrix Metaframe. Software that works fine locally on the desktop works differently (and sometimes not at all) on Citrix servers, and the problem is more pronounced using Terminal Services. Culturally, it is no big deal. That is what I think the problem is.
Theoretically, using Cygwin, or other techniques (like run as user like someone suggested), multiple concurrent users can be done. It isn't good though. Because (like someone else said) PC's are so cheap, people just don't try very hard. Therefore there is an underlying assumption that a problem with one PC mostly only affects the productivity of one user. Internet worms are shaking that tree, but there is still the idea that a PC keeps a user sandboxed. It's the assumption that one user or one PC factors in very little to the cost/benefit of the whole. If that's the way you want it, that's great, but you have to actually be responsible for that assumption by doing some risk reduction in the system design.
You have a correct, but oversimplified understanding of the requirements of supporting concurrency.
I'd say the only thing you really need to call an operating system "multiuser" is that multiple user contexts can be active at once, after that it's an issue of input and output.
You are SO right about the issue of input and output. Please try to consider what it takes to program a serial execution program that repeatedly operates on the same source of input and sink for output over and over. Then think about what you have to do differently to support threads. Then think about how to maximize thread concurrency (hint: it usually involves threads and event loops). Then zoom out and think about a kernel managing multiple processes in userspace.
I have no doubt that the kernels and low level facilities of NT through XP had sufficient process virtualization to support a good process separation security model. What I don't see is a history (if not current practice) of hackers (not necessarily the malicious type) and lusers sharing a running kernel. It's a hard problem to give the hackers the power to solve difficult software problems in novel ways and prevent their experimentation from breaking the system for simple users who barely understand what they are doing. The Opteron execution approval/disapproval stuff in XP SP2 is a significant step forward, but XP won't be secure until *NOT* doing that sort of thing is taboo. The discipline is not practiced in real life. Why bother with one user per PC?
All of the above mentioned operating systems are true securable multiuser systems.
OK. So they are securable. I think I failed to clearly make my real point. The APIs encourage bad security practice. Case and point: to put a user process inside a user sandbox, you have to get a handle on the user obeject from the OS. How long did it take Microsoft to think about the quality of their client/server password validation scheme? How much otherwise good software has been exploitable for how long before l0pht put out their famous password sniffer? What else did they overlook? What else have you got buried in there?
Also, my case isn't about the facts or the architecture or the exploits. Cutting to the chase: bad faith. Bad code is always rooted in bad assumptions.
If I'm trolling, then why do you reply with so much information? Or what.
I keep re-reading your reply, but I don't see a demonstration or depiction of multiple concurrent users. For argument's sake, Mac OS-X is not a concurrent multi-user OS. Darwin is though. If you can, I would be very interested in how multiple concurrent users can run arbitrary userspace programs concurrently on XP.
BTW: I *am* trolling, but not for flames. If you (or anyone else reading this) is so hot on XP, you could help inform me and win me over a bit with some of your experience. Until then, I've got a real lack of perspective here. I just don't see it!
"tl;dr: think & know before you open your mouth. Good advice in general. I would add RTFA/RTFM. In my experience, when one of those lessons is learned, the other is not far off.
Because Unix was designed for multiple concurrent remote users, protecting each users' environment (and the OS as a dependancy) was a core requirement and early design decision.
Because multiple concurrent remote users is not a feature of Microsoft Windows XP SP2, security will always be an afterthought. While it may be "securable" in that you can turn off almost everything, and maybe even default configuration in that mode is possible, security *breaks* desirable functionality. Apps must be written by design to accomodate security requirements or they will require turning off security features. When the apps are the reason you tolerate the computer and the OS, the conflicting requirements of the app and recommendations of the OS will quickly turn into an insecure ball of mush. Spyware is case and point: by mere existence.
The design philosophy of Microsoft Windows is to give developers unlimited power over the users they can acquire. These powers are supposed to be used for good, but there are no real checks and balances unless you are like Ralph Nader and can use the courts and organise class action. Even then, people get abused by negligent and malicious programmers. It is by design.
A PC is a user; a user is a means to power and money. Users are merely a means to another end. Whom does security serve? How?
A unix server is a community of users. The synergy of users in that community is a means to power and money. Plurality of interests and the common-ground and balance between them is the heart of unix. Whom does security serve and how?
Redmond does not believe in security. They believe you should feel secure, but you need not actually *be* secure. If you feel secure enough to pay them before you get uprooted, then maybe it is cheaper to put up a false front in the name of security? I'm not saying you can't do things right on Windows, but Redmond keeps making it so damned hard!
If you want Microsoft to make Windows secure, then demand to share a big fat beefy PC (with more than a few CPUs) with a few other users. Providing an environment where *peers* can trust each other is the foundation of secure computing. Demand it. Put up some ducats and show them how much you want it. Hold those ducats and don't give them up until you have the deal you want.
It's the difference between [being] awake and alert and simply working with a whip to your back.
I'm not disagreeing with you, but I want to raise a philosophical question for the benefit of people who don't really understand the critical link in what you said. I, for one, believe it is an enlightening insight.
You have drawn a dichotomy between the two situations of working slavishly, as in like a slave "with a whip to your back", and "[being] awake. Ironically, I believe you also mean that caffiene dependance is a situation on the slavish side of the dichotomy: caffiene is commonly associated with alertness and waking up.
There are two important elements of your aphorism, if you will suffer my analysis a bit. The first necessary element is the suggestion that caffiene dependence is related to slavery; the second is the suggestion that the common draw of caffiene is not necessary for alertness, but caffiene actually detracts from "being awake".
The argument itself is not specific to caffiene or dependance on it. It simply opposes slavery with being awake. The previous statement sets up the relationship by opposing being on caffiene with "feel and work much better, think much clearer, rest better, and actually code better!"
The problem I see with that is you suggest replacing a life pattern driven by addiction to sugar and caffiene with a disciplined and self-motivated mode of living. We may not assume that the unknown readers have sufficient seeds of discipline and self-determination to actually achieve anything in absence of caffiene. I would like to spin what you said by adding this.
Kicking any kind of addiction, or habit, or lifestyle, or whatever only requires two difficult things: suffering the consequences of the situation you are already in, and restraint from contributing necessary causes to future grief. In short: suck up and take it like a man while you starve the causes of your own greif. Caffiene is not as bad as opiates. If you learn this discipline on something like caffiene addiction, you can apply the discipline in tougher challenges. You can do anything. Or you can stay tied down.
The way this was supposed to work from the X500 and LDAP people, using ASN.1 syntax, is 'uid=joe,dc=mac,dc=com' would tell you to forward the authentication lookup to "mac.com" as "joe". I could theoretically do this from an AP owned and operated by dc=speakeasy,dc=net. The authentication thingie on the AP would ask its favorite directory for authentication service, and that directory would do referrals.
All you need to know is that you are "joe" at "mac.com" and the password to your Keychain(TM). If you like something other than MacOS X, then you will have to remember your WiFi password in addition to any other passwords:) .
BeOS predicted that eventually, Moore's Law would begin to fade or would periodically dip so that SMP systems would be employed to gain performance. The heavy threading will make it trivial to scale performance approaching linearity with the number of processors.
Think about fiber busses on the system board. Think stackable external CPU modules. Think Beowulf... (sorry, couldn't resist)
I bought my 5GB iPod just before they announced they were discontinuing it. I got a display model. It was a little scratched up, and the wall-socket charger was kaput, but my iPod is still going well today.
On taking care of batteries, Lithium Polymer batteries get irreversible decay every time you overcharge them even a little bit. Only charge them when you really need to. Just to make this more complicated: try not to run the battery down all the way. Charging a half or three quarters dead battery takes less out of the battery than charging it from cold dead nothing. Charging is hot, and heat destroys the battery. Sunshine is hot and sunshine destroys the battery. Don't ever ever ever charge your iPod while something else is also making it hot. For best results, wait until the battery shows half capacity and then charge it. When it gets about 80% full (shows 100% on the display), charge current drops to "trickle" level which requires another 12-14 hours to top off the battery. RC hobbyists will tell you how to get the most out of your battery, but remember you have the sophisticated computerized charger built into the iPod...
On the lucite scratches: I bought an Ace Hardware pack of 800 and 1600 grit sandpaper. I took the cover off my iPod and wet sanded it under running water with a piece of sandpaper stuck to a cutting board in my kitchen sink. Go in little circles with the 800 grit until the iPod dries off with no visible individual scratches smooth and uniform if cloudy, and then go up to the 1600 grit and go in little circles until it clears up. 1600 grit won't get you crystal clear, but a little buffing makes everything shiny and new. Nice!
Slashdot Mirror
In case you haven't been over to w3.org in a while, the HTML/XHTML standards are approaching the layout capabilities of FrameMaker. They're up against the Gecko engine, and the larger trend of dead-tree going out of style. Not that paper is dead, but you will probably skim electronic versions of anything before you want to carry around the paper version. There is additional energy cost associated with publishing on paper, and the cost of energy threatens to climb to 1973 levels. Electronic media reduces our dependance on fossil fuels for communication and information transfer.
I would guess this is news that Adobe FrameMaker is in "sunset mode." With Gimp coming up on PhotoShop's heels, the crops of Adobe bigots (the real value of the company) coming out of college may be in decline. Thus, Adobe may be in decline in a broader scope. Maybe they are going out quitely, and maybe they are circling the wagons. I'm sure there are hurt feelings regarding the iPhoto flap. The problem is: the only strategy Adobe has in fighting Apple is to lose.
Maybe Adobe is gearing up for a last-hurrah rewrite of the be-all end-all multimedia production suite? Then again, isn't multimedia so 1990s?
A) My "ticket" suggestion precludes assuming you need any certain amount of sales to break even. Instead of raising the revenue requirements and the risk, lower the production cost until it meets a comfortable risk level.
B) Regarding your #1: You don't have to wait 5 years. You are one person. Everyone can decide how long they want to wait. Its another free-market decided issue.
C) Regarding your #2: If you can wait a few years to get it, then the artist has not done a very good job at making a compelling piece of art/promo. If you can wait that long, maybe you're not a reliable source of revenue. I don't think you're much of a factor except you will probably buy some other competing stuff instead.
Maybe the author of this hypothetical book can write a foreword and then ue that to sell tickets for the book before he writes it or after he writes it but before he releases it to anyone. Think of how movies are marketed with trailers before they are finished.
It doesn't matter how long it takes the artist to produce the work. Maybe the work can be released in iterations like chapters or scenes. Maybe you will have to actually earn people's respect for your creative abilities before you ask them all to fund a big project. It should be easier for an artist/author to get *some* money from a lot of regular joes than it is to get a lot of money from a few producers/publishers.
It used to be hard to make intellectual property that was compelling enough to justify the enormous cost of distribution. Since the distribution costs and production costs forced each other up, there was a lot of sunk-cost to deal with before any customers even had the option of paying for the product. Now, distribution costs are so low that you can do as little or as much production as you want, and you can distribute it nearly for free if you use peer-to-peer distribution networks. Software like Apple's iLife suite lowers the ante on production costs to within reach of nearly any high school or college student, let alone professionals moonlighting as film or recording artists.
Maybe most of the product will not be that good, but there is still no reason to involve the massive and massive expense of a full-blown 1980s style music or film production. For example, people routinely pay for concert tickets (guaranteed delivery) of a performance--sight unseen. If too few tickets are sold, the show is cancelled, and the ticket holders are refunded. Why not sell download tickets for yet unfinished films and albums? Then the fan base can directly fund proven popular artists' productions.
I recognise that some artists and a lot of middlemen enjoy lots of residual income from past production work. Why is it so hard to recognise that this is not the only way to pay artists for their work, and there may be better ways if we think about it? The way I see it, copyrights only protect residual income, which pays artists and middlemen to NOT produce new material. Why do people think this is good?
This is not surprising. It is only controversial because some people desperately *want* to believe that Microsoft is good. This is a juvenile reaction to the bad-mouthing that Microsoft gets. This constant bashing is in bad taste, but whether it is fair or not will be borne out entirely by the facts that are unfolding before our very eyes.
The problem with Microsoft and all of their drone customers is that the relationship is not mutually beneficial. It seems so, however, to the dupes who take the terms that the vendor pitches them. The problem with bashing the house-of-cards is all of the hurt feelings involved with people who realize it too late.
So, try not to say anything bad about Microsoft. Just be compassionate towards the people who are suffering. Try to help people realise how much they are sharing the pain with others... no wait... you'll just end up saying the same things that piss off the Microsoft drones. On second thought, just keep a CDROM on hand with something better to install, and give it to the tortured drones with a smile and your head cocked slightly to one side (AOL style). Don't say a word. It isn't necessary or even helpful.
Like to roleplay?
You show up to work every day and take the paycheck even though you KNOW what you are bing told to do is BAD AND WRONG. Tell me again mister hypothetical "good" Microsoft developer: why should you be excused from ethical responsibility? The devil made you do it? Hrm?
Let me tell you that I am not impressed with this crap. Does anyone remember Mac HFS file format used to do "resource forks" to contain extensible metadata on files. The Finder would know, for instance, that the last time you opened a particular file, a particular progam was used to save it. The default action for that file if you double-clicked the icon was to open it with the last-saver application. The problem isn't getting the metadata out there. Been there; done that, for years. The problem is indexing all of it. What? Are you going to put a Google style cross-correlation engine on your PC to grind through the FS metadata indexes every time you change a file? How do you tell which metadata is worth all of the effort? The worst case workload increases geometrically with the number of files and the kind of metadata.
What about BeFS? It took this problem on and made demonstrable progress. If you searched your filesystem with find(1), you would match MP3s by artist name.
The problem is, Microsoft's department of predation^H^H^H^H^H^H^H^H^Hinnovation is looking at these two ideas and asking the question, "How can we use this to squeeze a few more dimes out of our captive market?" They want blood, and it is the very personal connections between the rich collection of data on your hard drive, and how you personally relate it to your life. While they try to convince you what it would be worth to you, ask yourself what it's worth to them!
The first thing I see is the suggestion that there should be a "contacts" file type built into the OS to handle all of your contact data. Maybe this should be validated against a master database in Redmond? Maybe they are just aching for the warm feeling they get from that good-old lock-in of captive data and the phantom control it gives them over ISVs.
Can anyone else think of any nasty easter eggs we all might find in WinFS (besides the poo-poo'ing that they gave metadata sharing/privacy choice)?
You see, the federal government has a constitutional, and historical jurisdiction over interstate commerce. If it gets to a turf war, then NO states will be able to levy excise taxes on interstate commerce, or (more likely) states will be required to adhere to the US Dept. of Commerce rules. That will allow federal officials like the US. President from having to commit political self-injury of imposing a new, unpopular federal Internet sales tax.
To understand this issue you must understand the role government plays in protecting and fostering and regulating commerce on all levels--not just sales. If disputes arise over the sale, which state will adjudicate the dispute? Now the State of Kansas has a tax-revenue interest in making their consumers^H^H^H^H^H^H^H^H^Hcitizens available for e-commercial harvest by the corporations who can $$$$ lobby their smalltime statehouse officers.
Maybe I mushed this up a bit. I remember vaguely that after the USDoJ got the findings of fact, several states sued for damages based on them. I remember at least one of them gave credit to Microsoft for copies of Microsoft products donated to schools, etc. That gets my hackles up.
For all of our sakes, I hope you are right!
In the US, the courts found that in fact, Microsoft had violated the Sherman Antitrust Act, ruling just short of a "guilty" verdict that no more arguments on facts of the case would mitigate a guilty verdict. The Sherman act is not civil law. It is criminal law. At this point, Microsoft shifted from a not-guilty stance, to negotiating a settlement with the USDoJ. The courts waited patiently. They dragged it out as long as they could, and ultimately got a monopoly-friendly US President in charge of the USDoJ to relax the pressure. The kids are now guarding the cookie jar.
Microsoft is not really a technology company. They are an Intellectual Property (IP) law firm trying to maintain IP assets. They will fight like dogs. That's what they do. They are dogs.
I am begging any europeans reading this to make a holy noise about "COUPONS FOR MICROSOFT PRODUCTS WILL NOT BE ACCEPTED IN LIEU OF CASH". It's bad enough that we have Jethro Clampett in the US presidency, in charge of the USDoJ and the people's interest in the MS antitrust issue. Please help make sure the goon's mistakes are not mirrored in the EU! Also, don't accept any namby-pamby payment plans. Get the lump-sum immediately, or seize assets and slap extra fines for delaying payment.
What I'm whining about is mount_mfs. You used to be able to add a /tmp or /var/run filesystem to fstab with a "mfs" type and the "-s256M,2,0" in the mount options, and thus get it to mount up along with /usr and /var before any userland software starts using /tmp or /var/run.
There isn't (the last time I checked) a clean way to do that in 5.0, and I have the prejudice that it should be part of the default install. If you want a persistent /tmp or /var/run, then it should be your special config, IMHO.
I run FreeBSD 5.x as a desktop machine, and I don't find it lacking. Small things get my goat like 5.0 taking away the ability to mount a MFS /tmp out of /etc/vfstab, and having to hack it into the rc scripts, and having to REDO it every time you upgrade...
One of the biggest piles of bullshit is all the Linux developers who can't write cross-platform code. They get all sloppy with introducing Linux dependencies when it isn't really necessary, and then someone like me has to beat on it mercilessly to get it to configure or compile on FreeBSD. Then people say "FreeBSD is behind on the desktop because it doesn't have BLAH latest BLAH." The cloud of flies on the bullshit comes from people saying that it is too hard to use the Ports tree when they want some software BLAH or blatently disregarding the fact that NVIDIA GLX DRIVERS work just fine and saying you need that for BLAH game.
The implicit assumption that FreeBSD should support KDE's buggy cross-platform-problem apps instead of the other way around makes me sigh.
Linux distributrions are very very duct-tape and drywall screws holding things together. I'm not so familliar with FreeBSD 5.x yet, but 4.x and 3.x and 2.x were all very easy to read. If source code is really important to you, you will be able to confirm this by reading the stuff. I disagree with all the "integrated feel" arguments as they are highly subjective and vague.
The bottom line is, Linux is definitely better for root lusers because too much software is written for dirty Linux users who run gnome-session as root. FreeBSD requires some ingenuity or effort that these developers could not be bothered to exercise. However, lets say that the forward-thinking design principles of the FreeBSD project keep old servers humming along for years while sysadmins can say "I guess someday I should upgrade that server," and never really get around to it.
Read the article on the process scheduler to see why you might prefer to suffer the pangs of debugging sloppy Linux software to get a FreeBSD desktop system up and running.
The goofiest thing is that if you want to run Darwin without the Quartz Window Manager and MacOS X GUI, you can run XDarwin and get essentially what you would get running a PPC build of FreeBSD 4.x on Apple hardware.
Some things give me grief, but I prefer Jaguar and even moreso Panther to Gnome and KDE and WindowMaker and AfterStep and FVWM2. Little things get me like having Terminal.app windows stacked so that the man page is under the top window with just enough transparency to read the obscure command options while I tweak the script in the top window's vi. Even a year later, I catch myself thinking "Nice!"
I disagree with the analysis.
Specifically, I tested my own sparcv9 OpenSSH on sparcv9 OpenSSL compiled with GCC-3.2.1. I got different results, and I have a different conclusion. My needs are to scp 8GB database dumps from one host to several others. I was interested in two factors. First, if run time was significantly different, that would be a compelling factor. That factor accounts for economy in scarce maintenance window time which I can safely saturate the network. Second, I was interested in the amount of system resources consumed during the process.
My results were different from the OSNews guy, but then again I am not intimidated by gcc make bootstrap. My sparcv9 OpenSSL libcrypto was carefully configured and compiled to use as much of the sparcv9 assembly code as the OpenSSL project provided. Both of my hosts were Sun Fire V880s with 4x750MHz Ultrasparc-III CPUs running 64 bit Solaris 8. SSH was configured to use the Blowfish symmetric cipher because it is not as CPU expensive as 3DES or AES in software. The disk volumes of the source and sink were EMC Symmetrix volumes over 1Gbps FC SAN using Emulex 900x host adapters. Over several trials, neither 64 nor 32 bit SSH could claim a run time advantage. However, the user-CPU time (number of cpu cycles spent executing SSH code as opposed to time spent waiting for IO service times or kernel/syscalls to complete) for the Sparcv9 SSH was slightly more than half of the same statistic for the Sparcv7 binary.
Admittedly, there is a difference in my benchmark test cases aside from instruction or data word length. Sparcv7 has no integer multiply or integer divide instructions, so it must rely on long-division and repeated adding to achieve the results of those operations. I needed a sparcv7 binary because I still have one old sparcv7 box in service that needs SSH. Because of the cache hit ratio when doing that kind of math, and the fact that Blowfish does not rely heavily on those operations, I doubt that these instructions would account for the difference in CPU cycles required to process this 8GB file.
Confirming this is difficult because the sparcv8 ABI was a 32 to 64bit crossover architecture in which the OS would interperet and optimize some operations if they were running on a 64 bit Solaris (2.7 or 8) kernel. Thus, a 32 bit sparcv7 binary running on sparcv9 hardware and a sparcv9 kernel may actually be partially executed in 64 bit mode, and be efficient at it. If there are any sparc ABI guru comments to enlighten us on the specifics, those comments would be appreciated. I believe a more rigorous test would verify that the kernel running the 32 bit userland software was a 32 bit kernel.
I conclude that the large data word size allowed SSH to encrypt the 8GB file in nearly 50% fewer CPU cycles, and therefore is faster for this type of operation. Aside from that, note that RSA/DSA operations on the sparcv7 binaries are SIGNIFICANTLY slower, probably due to the multiplication and division required by those algorithms. I'm sorry I wasn't doing this benchmark for publication or I would have saved my data/results.
My sentiments exactly. Moreover, how is this going to kill iPods? Its just the competition we need to get more from either Apple or Microsoft. Bring it on! I have a 5GB first generation iPod, and it still rules. If replacement hard drives were available at larger sizes, I wouldn't even think of letting it go. iTunes smart lists are making it easier to stretch the 5GB since my CD collection is over 10GB at 160bps MP3 compression. It is a significant part of my lifestyle now, but its going to take a lot to make me give it up. Something better? How much?
Where I work, they license and use Citrix Metaframe. Software that works fine locally on the desktop works differently (and sometimes not at all) on Citrix servers, and the problem is more pronounced using Terminal Services. Culturally, it is no big deal. That is what I think the problem is.
Theoretically, using Cygwin, or other techniques (like run as user like someone suggested), multiple concurrent users can be done. It isn't good though. Because (like someone else said) PC's are so cheap, people just don't try very hard. Therefore there is an underlying assumption that a problem with one PC mostly only affects the productivity of one user. Internet worms are shaking that tree, but there is still the idea that a PC keeps a user sandboxed. It's the assumption that one user or one PC factors in very little to the cost/benefit of the whole. If that's the way you want it, that's great, but you have to actually be responsible for that assumption by doing some risk reduction in the system design.
You have a correct, but oversimplified understanding of the requirements of supporting concurrency.
You are SO right about the issue of input and output. Please try to consider what it takes to program a serial execution program that repeatedly operates on the same source of input and sink for output over and over. Then think about what you have to do differently to support threads. Then think about how to maximize thread concurrency (hint: it usually involves threads and event loops). Then zoom out and think about a kernel managing multiple processes in userspace.I have no doubt that the kernels and low level facilities of NT through XP had sufficient process virtualization to support a good process separation security model. What I don't see is a history (if not current practice) of hackers (not necessarily the malicious type) and lusers sharing a running kernel. It's a hard problem to give the hackers the power to solve difficult software problems in novel ways and prevent their experimentation from breaking the system for simple users who barely understand what they are doing. The Opteron execution approval/disapproval stuff in XP SP2 is a significant step forward, but XP won't be secure until *NOT* doing that sort of thing is taboo. The discipline is not practiced in real life. Why bother with one user per PC?
OK. So they are securable. I think I failed to clearly make my real point. The APIs encourage bad security practice. Case and point: to put a user process inside a user sandbox, you have to get a handle on the user obeject from the OS. How long did it take Microsoft to think about the quality of their client/server password validation scheme? How much otherwise good software has been exploitable for how long before l0pht put out their famous password sniffer? What else did they overlook? What else have you got buried in there?
Also, my case isn't about the facts or the architecture or the exploits. Cutting to the chase: bad faith. Bad code is always rooted in bad assumptions.
If I'm trolling, then why do you reply with so much information? Or what.
I keep re-reading your reply, but I don't see a demonstration or depiction of multiple concurrent users. For argument's sake, Mac OS-X is not a concurrent multi-user OS. Darwin is though. If you can, I would be very interested in how multiple concurrent users can run arbitrary userspace programs concurrently on XP.
BTW: I *am* trolling, but not for flames. If you (or anyone else reading this) is so hot on XP, you could help inform me and win me over a bit with some of your experience. Until then, I've got a real lack of perspective here. I just don't see it!
"tl;dr: think & know before you open your mouth. Good advice in general. I would add RTFA/RTFM. In my experience, when one of those lessons is learned, the other is not far off.
Because Unix was designed for multiple concurrent remote users, protecting each users' environment (and the OS as a dependancy) was a core requirement and early design decision.
Because multiple concurrent remote users is not a feature of Microsoft Windows XP SP2, security will always be an afterthought. While it may be "securable" in that you can turn off almost everything, and maybe even default configuration in that mode is possible, security *breaks* desirable functionality. Apps must be written by design to accomodate security requirements or they will require turning off security features. When the apps are the reason you tolerate the computer and the OS, the conflicting requirements of the app and recommendations of the OS will quickly turn into an insecure ball of mush. Spyware is case and point: by mere existence.
The design philosophy of Microsoft Windows is to give developers unlimited power over the users they can acquire. These powers are supposed to be used for good, but there are no real checks and balances unless you are like Ralph Nader and can use the courts and organise class action. Even then, people get abused by negligent and malicious programmers. It is by design.
A PC is a user; a user is a means to power and money. Users are merely a means to another end. Whom does security serve? How?
A unix server is a community of users. The synergy of users in that community is a means to power and money. Plurality of interests and the common-ground and balance between them is the heart of unix. Whom does security serve and how?
Redmond does not believe in security. They believe you should feel secure, but you need not actually *be* secure. If you feel secure enough to pay them before you get uprooted, then maybe it is cheaper to put up a false front in the name of security? I'm not saying you can't do things right on Windows, but Redmond keeps making it so damned hard!
If you want Microsoft to make Windows secure, then demand to share a big fat beefy PC (with more than a few CPUs) with a few other users. Providing an environment where *peers* can trust each other is the foundation of secure computing. Demand it. Put up some ducats and show them how much you want it. Hold those ducats and don't give them up until you have the deal you want.
Interesting:
I'm not disagreeing with you, but I want to raise a philosophical question for the benefit of people who don't really understand the critical link in what you said. I, for one, believe it is an enlightening insight.You have drawn a dichotomy between the two situations of working slavishly, as in like a slave "with a whip to your back", and "[being] awake. Ironically, I believe you also mean that caffiene dependance is a situation on the slavish side of the dichotomy: caffiene is commonly associated with alertness and waking up.
There are two important elements of your aphorism, if you will suffer my analysis a bit. The first necessary element is the suggestion that caffiene dependence is related to slavery; the second is the suggestion that the common draw of caffiene is not necessary for alertness, but caffiene actually detracts from "being awake".
The argument itself is not specific to caffiene or dependance on it. It simply opposes slavery with being awake. The previous statement sets up the relationship by opposing being on caffiene with "feel and work much better, think much clearer, rest better, and actually code better!"
The problem I see with that is you suggest replacing a life pattern driven by addiction to sugar and caffiene with a disciplined and self-motivated mode of living. We may not assume that the unknown readers have sufficient seeds of discipline and self-determination to actually achieve anything in absence of caffiene. I would like to spin what you said by adding this.
Kicking any kind of addiction, or habit, or lifestyle, or whatever only requires two difficult things: suffering the consequences of the situation you are already in, and restraint from contributing necessary causes to future grief. In short: suck up and take it like a man while you starve the causes of your own greif. Caffiene is not as bad as opiates. If you learn this discipline on something like caffiene addiction, you can apply the discipline in tougher challenges. You can do anything. Or you can stay tied down.
The way this was supposed to work from the X500 and LDAP people, using ASN.1 syntax, is 'uid=joe,dc=mac,dc=com' would tell you to forward the authentication lookup to "mac.com" as "joe". I could theoretically do this from an AP owned and operated by dc=speakeasy,dc=net. The authentication thingie on the AP would ask its favorite directory for authentication service, and that directory would do referrals.
All you need to know is that you are "joe" at "mac.com" and the password to your Keychain(TM). If you like something other than MacOS X, then you will have to remember your WiFi password in addition to any other passwords :) .
Well, once you get a few more CPUs, and you learn to push the vector math to the vector processor, then you begin to feel the difference.
BeOS predicted that eventually, Moore's Law would begin to fade or would periodically dip so that SMP systems would be employed to gain performance. The heavy threading will make it trivial to scale performance approaching linearity with the number of processors.
Think about fiber busses on the system board. Think stackable external CPU modules. Think Beowulf... (sorry, couldn't resist)
I bought my 5GB iPod just before they announced they were discontinuing it. I got a display model. It was a little scratched up, and the wall-socket charger was kaput, but my iPod is still going well today.
On taking care of batteries, Lithium Polymer batteries get irreversible decay every time you overcharge them even a little bit. Only charge them when you really need to. Just to make this more complicated: try not to run the battery down all the way. Charging a half or three quarters dead battery takes less out of the battery than charging it from cold dead nothing. Charging is hot, and heat destroys the battery. Sunshine is hot and sunshine destroys the battery. Don't ever ever ever charge your iPod while something else is also making it hot. For best results, wait until the battery shows half capacity and then charge it. When it gets about 80% full (shows 100% on the display), charge current drops to "trickle" level which requires another 12-14 hours to top off the battery. RC hobbyists will tell you how to get the most out of your battery, but remember you have the sophisticated computerized charger built into the iPod...
On the lucite scratches: I bought an Ace Hardware pack of 800 and 1600 grit sandpaper. I took the cover off my iPod and wet sanded it under running water with a piece of sandpaper stuck to a cutting board in my kitchen sink. Go in little circles with the 800 grit until the iPod dries off with no visible individual scratches smooth and uniform if cloudy, and then go up to the 1600 grit and go in little circles until it clears up. 1600 grit won't get you crystal clear, but a little buffing makes everything shiny and new. Nice!