By revoking a player's key that is being exploited to acquire title keys, *new* pressings of discs will not be susceptible until they figure out how to exploit another program that still has a valid key.
It's true, once the player's key is effectively compromised, any current disc that player can play is vulnerable, but new releases and new pressings of the current releases can be made unreadable by that player.
On the work backwards from a title key to the player key, I'm not sure I understand who you are asking about. I'm assuming you are saying how would they know which key to revoke. The answer is not based on the released keys, but on comments/watching the video. I think there are a grand total of two pieces of software currently, and one of them is used clearly in the video. In this particular instance, they know to take a long hard look at PowerDVD, but to be on the safe side, look at the other one and maybe revoke them both. The size of the market you have to piss off is very small at this point. If, say, 30% of the general population had a large variety of HD-DVD playback options, figuring out the key to revoke could be troublesome and piss more people off when/if they did.
Of course, if no player key is released, it remains a pain in the ass to play back an arbitrary disc, and, in fact, you *must* download the probably copyrighted title/volume key from the internet. Which means even in the absence of DMCA they can slap parties with distributing and downloading copyrighted material, even if they can't prove anything illegal with the actual movie content. It's essentially brought it up to the same level of pain in the ass as finding product keys for standalone software.
Revocation accomplishes nothing (except, as with most DRM, annoying legitimate users) if the cracker can get the key dynamically. Well, the assumption is that the approved software they are using to acquire the keys won't manage to make it impractical to exploit it to grab keys. If they somehow manage it (cannot think of how they would, but I'm not in the field and this is for sake of discussion), the party is over for new pressings of discs. Of course if that key is extracted from/shared with a set top box, the industry would have to piss people off more thoroughly than just demanding a software update. On the other hand, I wonder if they mandate all boxes must be upgradeable, and any company who's key is compromised is required to send to customers update media...
Here's the other part I don't understand about the described methodology. Someone said in a nutshell that the disc's keys are stored encrypted in all the players' keys. If each vendor has their own key, what happens 6 months down the road when a new vendor gets into the market, needs a key, and wants to play already released discs? Or have they already allocated a whole bunch of keys and not released them?
Looks like from his FAQ that he figured a deterministic way a particular piece of HD-DVD software stores the key in memory. Of course, it's always going to be the case the key is in memory during playback, finding the address would be the pain.. Wonder how he knew what to look for so quickly... Well, suppose he did have a couple of distinct movies, he probably had a set of addresses that obviously changed between discs or titles, and probably some tell-tale strings...
So he probably doesn't have the program's key (it would be in memory a short time probably if well implemented, but ultimately probably gettable, if the program can read it's own key, anyone can). However, expect content providers to audit how easily the key material is locatable in memory (i.e. how deterministic the key memory address is relative to program base address) and revoke keys in future pressings and force upgrades to software users.
Of course, with a few keys out it becomes problematic to hide the locations. Ultimately, the program has to know the offset to the key to use it, so there are going to be hoops to jump through, but using a known title with known key means the address of the key can be found and sampled over a few playback attempts, the memory address of the program analyzed to see if some pattern emerges or some variable points the right way....
BTW, if it was PowerDVD (which he never explicitly said), he is cocky actually showing that program running in his demonstration. PowerDVD is going to be under careful analysis now and his job will be made more difficult likely.
Of course, he could be more clever than I'm guessing, but the indications seem to be memory analysis of HD-DVD playback software.
Anyway, beyond making more hoops to go through, content providers cannot be so stupid as to think the problem technically insurmountable. It's all about demonstrating clear intent to violate DMCA and take legal rather technical measures to 'deal' with the problem.
I agree at its core, it isn't technically a bribe, but it is questionable.
Well, record labels will send free CDs, t-shirts, and other materials. CDs are a requisite for review, so they don't count. Since they are the product in themselves, no one is inclined to get even more samples of something they don't like. If someone doesn't like Nickelback, they won't lie and say they love Nickelback to get more Nickelback CDs. Now if they shipped a high quality stereo to play the CD on, that would be an analogy. shirts and trinkets are marketing fluff that no one tracks and it doesn't impact review decisions, though they probably get a little more advertising out of cheap people.
Movie studios will fly reviewers out to special reviewer-only screenings of their films in a high-end theater. Closer, but the reviewers don't get to keep the theater. There is an implied benefit of future paid trips but it really depends on the destination and duration of the trip as to whether its practical or not. They want to control distribution of the film, so they don't want to send DVDs, and it is more expensive to set up many venues, so the most practical solution is pulling people in. If they pay for a 5 day trip, it's excessive, but if it is round-trip airfare and no more than one night's hotel, it could be reasonable.
Microsoft wants Vista to be run on the best possible hardware for it, so they'll send out laptops with Vista preloaded. It's not common to need to send out something of that scale with a product sample to evaluate it in other industries (CDs aren't sent with nice players and speakers/headphones, etc etc). However, it could be a requirement for their marketing to have reviewers take a spin on a well-understood laptop, so I could give lee way, however there is precedent in the computer industry they break, details to follow....
You do realize they can send the laptop back to Microsoft when they're done reviewing Vista on it, right? The point is MS is not asking for them back. If MS said "this is a demonstration loaner, must be returned" (which, btw, in the computer industry is *VERY* commonplace, half the equipment I work with we get for a limited time and have to return), no one could accuse them of impropriety (unless, of course, they said to keep it if the review is good). Just because a reviewer *can* return it doesn't mean it absolves MS of guilt. It's not a bribe if MS doesn't demand a good review in exchange, but it is a conflict of interest, because reviewers who hate MS products may be inclined to lie to get the hardware gifts which are not MS product.
Whether it is a bribe or not-so-shady marketing is not a measure of the value, it's whether there are strings attached. However, shipping their own product is appropriate, shipping the laptop may not be a bribe outright, but it certainly is questionable.
If the recipient takes the gift talks about how shitty MS and Vista are, and MS can't take back their gift, it's not really a bribe. There is a logical assumption to make that such gifts would be less likely to occur if the reviewer doesn't do good by MS, and this opens the door to question bundling the laptop, but it technically remains not a bribe.
If the gift was contingent on a good review, it is certainly a bribe.
Now it becomes questionable because any good press coming from those who received laptops comes from those with a conflict of interest. If it had just been a free copy of Vista, and they didn't like it, they wouldn't be motivated to lie because all they have to gain are more free copies of a product they don't like. However by linking a laptop in, the reviewers may be inclined to look good to MS in the hopes of getting the laptops, even if they blow away the software on it after review because they truly thinks it sucks.
If the laptop vendor had sent the laptop, no big deal. After all, the reviewer only has to kiss ass of his favorite sample-providing vendor because the other products are inferior and he doesn't care.
I haven't had many problems in terms of longevity. Three of my systems did develop severe issues over the years, but invariably some fan in the system (1 chipset, 1 case fan, and 1 video card fan) had either stopped spinning or was spinning slowly and generating heat itself instead of mostly moving heat as it should. Replacing the fans resolved each problem. General rule of thumb is that if weirdness develops over time and persists through different OSes, hunt down bad fans and if you are lucky, no permament thermal damage has occurred. I had one motherboard blow capacitors, but that's usually a fairly hard failure, but you may want to check for non-flat capacitor tops. Aside from specefic capacitors, solid state devices tend to do well over time, so the likely culprit is some moving part (fan, hard drive).
I happen to buy almost entirely from Newegg (there is a local Tiger Direct outlet here, but they tend to be pricier than NewEgg. On the frontend I got motherboard, processor, RAM, and case/PS, so few interactions to go south, and few moving parts (3 fans). A system with a Promise SATA controller didn't work well with the sata_promise linux driver on the backend (concurrent IOs to multiple channels would knock the controller out of commision), so I bought a silicon image.
The SQL is generally transparent to the user, but sometimes granting privileges requires SQL statements be crafted/issued in a more complex backend/frontend config. Mainly I think they found it a convenient way to manage TV listings, and if requiring a DB, may as well use it. Also a natural way to share a config between backends and frontends. With only one mythbackend and some number of frontends, you don't need any file sharing to do the meat of mythtv.
First off, it was a moderate/somewhat hard effort for me. Keep this in context, though, as my day-to-day job involves putting together similarly complex net booting stuff, so diskless systems are old hat for me. Running X, booting it so it can sleep and be diskless, and doing it all in such a small amount of memory were challenges beyond the everyday (systems I work with rarely run X, never sleep, and always have gigs of ram). Myth itself is documented pretty well, but indeed has a lot of options and requires mysql to be running. For backend/frontend operation it's a little funkier and knowing SQL helps things, but guides are all over the place about that. So it will probably not be easy (I enjoy challenges, and learned a fair amount, particularly with the flexibility of trying different things I don't have the time to do at work)
Also, an ongoing issue is that mythtv 0.19 (haven't moved to 0.20 yet) forgets AV sync adjustments on seek. Related to this, some of my recordings end up ~500 ms out of sync from the beginning, for no discernible reason. The GeForce 6150 is up to a lot of tasks, but starts to choke on the level of ePSXe with the XGL2 GPU plugin (which is the most glitch-free, but demanding GPU plugin). The MesaGL plugin is fine, looks better (XGL2 renders to a texture and so aliasing is largely dictated by the resolution of the texture which is generally much smaller than your resolution, MesaGL renders direct to screen), but is subject to more glitches. Most gaming on this box is Mame/ZSNES/etc, so ePSXe is the most complex GL program I try to run. I have the games and a PSX and a PS2, but none look nearly as awesome as ePSXe at 960x720 (actually 1280x720 is the mode I select, but preserving aspect of course takes it down to 960x720 effective. Preserving aspect and using the full 1280x720 mode is the way to make it center on screen.) Also nothing beats the convenience of clicking on the games you want instead of media hunting and swapping.
The frontend is diskless, no hard drive or flash, netboots off the backend. I started with slax and heavily modified it so it runs off of a ramdisk root and nfs mounts most everything. I did this because it allows the box to sleep (ACPI S3) and resume despite being diskless. If I did nfs root, it couldn't access the utilities/libs to get the network straight again, usb flash disk similar story, it seemed that it wouldn't bring up usb good enough on resume, so ramdisk was my answer. The frontend, btw, was an Asus A8-VM CSM based system with 512 MB of RAM, if you want to know a system with sane enough ACPI to actually sleep under linux (with latest BIOS of course). If you splurge on 1 GB or more of ram, you don't even have to work to trim things down for the ram disk or putting it on nfs to get off the ram disk, and a vanilla slax with copy2ram would go a long way toward what you ultimately want. I really should write a howto somewhere, don't know where since I spent a fair amount of time getting everything to work without a disk and sleeping on a 512 MB ram budget and putting SLAX in a workable form to boot from tftp/nfs.. It was a lot of work, but I have a very quiet frontend with only fans as moving parts which don't need to ramp up much.
The backend has 4 250 gig drives in a software md5 and has the airstar HD5000 card in it (might recommend the new pcHDTV card which is basically the same thing, but the company is very explicit about the linux support. I use pcHDTV provided drivers for my card for some SNR/signal strength values, but am not convinced the formula for the pcHDTV is quite the same as HD5000... Anyway, the big advantages here are I have a huge case for the backend, lots of fans to keep things cool, and can keep it far from my frontend. My house has RJ45 drops everywhere, so I don't know first hand feasibility of 802.11g doing the job for less fortunate souls. 100 mbit is fine and HD content at 1.5x pitch shifted consumed no more than 35 mbit in my tests, but realistic 802.11g performance depends on your environment and I'm not sure what the feasible max or sustainable max is.
Anyway, I set up an analog set up before and a HD setup now. Keep in mind I only do over the air stuff with an antenna, cable and satellite complicate things beyond what I know. I have MythVideo to play DVDs and video files for cable-only or foreign content not licensed in the US (anything worth watching on cable ends up in a box set, is generally not HD on US cable channels, and it's cheaper to pick and choose that way given my watching habits). Setting up digital only, at least in the over the air case, was easier than the old way. The analog way you had to sweat the quality of your signal a lot more, and the quality of your tuner was more critical. Guys at work have cable and struggle with analog setups to get the quality of the capture nice and try out different cards (Cable company is far from all-digital, and encrypts a lot of the digital channels anyway) Digital your card simply has to have a comfy margin above the bare minimum, and copies the stream to disc, no subjective quality to worry about, you have exactly the data the broadcaster intended.
The backend if that is all it does, doesn't need much of a processor, but fast storage subsystem that is not heavily multitasked is a must. Don't have transcode jobs run when recordings are likely to happen concurrent, IO starvation could lose too much of the digital stream and cause bad artifacts. Playback during recording I haven't noticed problems.
The frontend needs to have a video card that supports XvMC, and/or a fairly nice processor. I have an Athlon64 1.8 GHz, which could do it without XvMC at 1.0x speed, but it cuts it close on some content. Plus, if the processor load is high too long the fans will start spinning faster. Pitch shift to 1.3x and some content will choke. The Asus I mentioned earlier has integrated GeForce 6150 and nvidia's drivers provide XvMC with it, and that drastically reduces the cpu load. Myth's wiki h
Also lists resolutions, which top off at 720x480. Definitely not HD preserving, and likely no HD tuner. Of course, an HD tuner PCI card is about $100, so it may have put the vendor over their price point.
Doesn't take much to support 16:9. Also is effortless to support most sets with HDMI and distinct audio ports with a DVI-HDMI cable.
I have a diskless mythfrontend on my TVs HDMI port, running 1280x720, and the backend has an HD Tuner. Absolutely beautiful.
Admittedly, the subject didn't register with me, and yes, cygwin will give you some of the niceties of a *nix system in Windows. It is a good first step if you want to see what you think of *nix command line interfaces, but may be less interesting in terms of graphical applications which generally already have non cygwin Windows ports that work about the same anyway
He implied a new system purchase, and presumably this is a good time to give an alternative a spin. There are two parts to his question, really. The first and stated part is if there is benefit to be had to transitioning. The second part which is left unsaid but undoubtedly on his mind is what might he be giving up while in linux. On the first part, cygwin doesn't have nearly the software library a distribution would with apt or yum repo, so a lot of the benefits would be unrealized. The second part obviously you won't get a feel for unless you have an environment devoid of the crutch of Windows to fall back on.
It's like a Linux distribution done properly. Everything works together properly, and EVERYTHING is well documented. This I never got, BSDs and OpenSolaris brag a whole lot about the wealth of documentation compared to linux, but in my experience, finding documentation on what you need is by far easier on linux systems than others. It's hard for it *not* to be the case given the relative user populations. Linux alternatives have their merits, but harping on documentation seems a weak point that can easily be disproved with simple google searches.
Besides, FreeBSD you'd have to pit against a particular distribution if you want to exclude unofficial-like user contributed documents. Most distros nowadays have Wikis that cover pretty much whatever you want.
On the ports system, I've not tried Fedora since its inception, so I don't know how yum repoes are, but definitely gentoo portage and debian apt repos are nicely searchable (apt-cache or something like synaptic for GUI stuff). The ports tree was an impressive advantage, but now linux distros are out there that are even easier to pull and install stuff without compromising some of the benefits of binary package management (fast installs, ability to quickly determine which package owns a file, etc...)
Ubuntu is nice but it is set up for a newbie with root access disabled. That is not a fair assessment. Ubuntu chooses not to give the temptation to always log in as a root user, and opts for the sudo to root only option. OSX also does it.
On serious servers even before OSX/Ubuntu adopted the strategy, in shared admin environments the root password was frequently not set in my departments, to force admins to sudo and provide a better audit trail so you know who to ask about activity when.
There is very little you need the root password for if you have designated admin accounts permitted by sudo to do various tasks. The only complaint I heard from a new admin was 'what about single user mode', to which I would respond if they get such a prompt and need to actually do something, boot a rescue environment. The other objection I could think of which would be valid is if/home is nfs mounted, nfs server is dead and you need to not stat nfs mounts while rectifying the system. This is not the case for most endu ser desktops, but it would be a case where root password being set may be prudent for emergencies.
This is not just a *newbie* thing to do. The bigger risk with having root a direct login is for people to get lazy and type root user/pass into a display manager login.
If the submitter never tries linux, how would they supposed to find out when it *would* be better for them? I think the description shows clearly he has reason (working with latex and python, and the platform is popular in the field he is working more into).
If they have the time and resources to evaluate a platform, particularly one that enjoys fair popularity in their field, they should do so.
In fact, I would recommend delaying a Windows license purchase on the new system entirely, unless transitioning his existing license from his old desktop. Leave Windows on the older system and see if Linux can fit the bill more than he realizes. Windows is not free by any legal measure, so already there is benefit migrating to a free platform and save a fair chunk of money (even XP home OEM is 90 bucks right now)..
Not recommended, the goal is clearly to be a university or similar workstation/server, adding AFS configuration and such as they repackage RHEL. Not a large community/yum repo, and not oriented to new users without competent administrators to complement them.
Debian and debian derivatives by far have the most rich environment and repositories. I haven't tried Fedora Core except a couple of times briefly, but by now they may have a fair yum repository.
I started with linux kernel 1.2.3 (was easy to remember) on a slackware distro back in the day.... ah the memories....floppy after floppy after floppy....
No thanks. I grew tired of dealing with obscure broken library dependencies on upgrades on my *own* systems, sure as hell don't want to have to answer someone who, in the process of emerge -upv world (or whatever it is anymore), ended up with applications linked to libraries with changed versions. I know there are utilities to automatically run ldd against everything (revdep or revbuild.. can't remember) and re-emerge, but in the end, big pain in the ass, and ultimately you don't learn that much more about linux like, say, doing a linux from scratch would teach if that were the goal.
Definitely would go with an Ubuntu install. Debian would also do the trick with little hand-holding, but at times Ubuntu is more practical about some packaging decisions while Debian can be more purist. Also, Ubuntu clearly targets a set environment, and Debian endeavors to make sure everything works pretty well, but expects the user to know more about what they want to make choices for themselves. Also, Ubuntu is easier to showcase the newer stuff typically (though Debian Etch and Ubuntu Edgy are about equivalent on that front currently).
I know what dd is, I was thinking you were implying dd was needed to extract cpio, but I realize you were just talking about doing rpm2cpio manually with dd.
I don't think the format of having a header that can be parsed without extraction is a bad thing, so long as the header provides all the functionality needed, which rpm does not.
But is it merely trying to get Mac apps to compile and run, or actually duplicate the whole user interface paradigm? Honestly speaking, the ability to simply run Mac apps isn't exciting, for the most part we already have good equivalents. It is appealing to use those projects under GNUstep because they were designed with that sort of user interface in mind unlike GTK/QT apps, but the applications in and of themselves have no features not implemented in the counterparts.
Well, to be more accurate, they cared about NeXT enough to base OSX off of it. GNUstep is the most API-compatible option that can run on alternative platforms. Of course, its not because of the API that it is so interesting as a desktop platform, and developers and users have come to appreciate it in OSX.
The two main open desktop projects (GNOME and KDE) heavily mimick the user interface paradigm established by MS. GNUstep is a good complement with the NeXT (also OSX) user interface paradigm (separate menu, management of windows individually and by application, applications registering services for more complex/powerful gui actions than what is done by drag/drop, copy/paste, etc).
GNUstep/NeXT/OSX services are the only appropriate equivalent of command line pipes in GUI land, which makes it a highly logical fit for those who understand the beauty and power of pipes in *nix. For example, in Gnome/KDE if an application wants spell check, they need to implement it themselves or at least take in a library and hook things around it. In GNUstep, any text application I can highlight something, click services/spell check if I have a spell check app installed, and it will happen. People complained for a long time about browsers not having spellcheck, but with services implemented and used browsers would have had it for free. It's kinda like piping the output from some command into aspell. All kinds of interesting things have been done with services, and someone implementing something new and different ends up enhancing all the desktop software that is appropriate for it without extra effort.
I have used GNUstep many a time to see how they are going, and if the environment were more complete (i.e. a GNUstep web browser, and IM client, office software) I would use it as my desktop full time. I remember before gcc had objc++ and before gnustep & gorm had nib support, that those two barriers going away was expected to allow all kinds of wonderful porting from OSX (i.e. the OSX Firefox code, one of their IM clients, whatever else). I haven't seen any word on efforts since those developments. I would love to contribute, but my plate is too full.
The downside is that in GNUstep more so than KDE/Gnome, non-native applications are really jarring, without separate menu and not interfacing with services. WindowMaker does a good job grouping windows by application for application hiding, but it isn't enough. Also GNUstep is capable of doing a lot, but fonts, for example, are a pain in the ass (at last check with the decent backend with anti-aliasing you had to package fonts in.nfonts). Also GNUstep could probably accomodate more of the freedesktop specification than they currently do, however I do recognize that freedesktop specifications pretty much have the MS way of doing things in mind and therefore some things aren't appropriate for GNUstep. Also, GNUstep doesn't have a perfect window manager to use with it. WindowMaker is very good, but doesn't render menus/dock in a way that is guaranteed to be visually consistant with GNUstep. WindowMaker is probably the best effort to focus on moving forward, but there is work to be done.
If you work it, GNUstep is a lot further along than most people realize, but the fact you have to work hard to get a complete environment discourages new users. And even when all is said and done, things are a bit rough around the edges in spots...
Right now the cost/benefit analysis of any medical research strongly favors treatments over cure. If investors see two projects with two possible outcomes, one with an expensive and inconvenient regimen for the rest of someone's full life, or a project that plans to have a 30-day cheap pill cure, the investors will lean toward the one *obviously* suboptimal for society, because ROI is higher.
If something like what you are talking about is done, more measures can be taken to level the playing field so that cures are financially as well as socially are better than treatments.
the less proprietary x86 architecture that took the market by storm in spite of it's design flaws.
Largely because IBM didn't realize what they were doing with the platform and MS. IBM's funding largely launched the platform using a large R&D buget, and a host of companies that would have been unable to otherwise get into the market latched on and largely undercut IBM (IBM's pricing reflected having to recoup R&D, which competitors didn't have to as directly. The irony of your example is that IBM allowed it in part due to patents. Back then to a large extent and today to a lesser extent, implementing an x86 PC involves on various levels paying IBM license fees to use patented strategies. IBM would *not* do the R&D needed for things to happen like the PC revolution without patent protection. If they had no legal recourse to protect their invention, they would either not risk the investment or otherwise find ways of making it near impossible to reverse engineer and keep the secrets tight and never license them out. Same with your example, you look at the current state of things, stating how freeing the patents would create a wonderful free market for existing research, but fail to demonstrate how big R&D budgets would be risked by companies if they know they are just going to be ripped off and undercut when the no-R&D company copies it.
Inventors are good at inventing things, so patents do really not help inventors or small lean innovators
Huh? I guess you are trying to say inventors have nothing to fear because they have plenty of ideas to go around? Again, oversimplifying (one could have one single brilliant idea), but even if accepted, it doesn't help. If you have a thousand ideas, and each takes 100 dollars worth of work to work the details into a marketable way, and at the end of the day, a guy can copy your idea with 10 dollars of effort per idea, when you get to market you will compete with someone who had 10% of the development costs to recoup that you do. The problem is not that invention is needed, it's that invention that costs non-trivial amounts in R&D to achieve becomes impractical due to the market realities of competition.
The point about violence inherent in the system (had to slip python in) seems kinda ludicruous. Never heard of violence-enforced patent situations. Automobile safety tech was not held back because of patents, they just didn't want to do it until the government forced them to. If government directly would not have, the increasingly litigious society probably would have forced the issue, but I digress. DDT was banned not because of patent expiration, but because they didn't understand the implications until then. Plenty of such things have been banned by the government well before patent expiration. Freon similarly was part of the 80s environmental push, the timing coincides with too many other regulations to have them all be tied to freon patents. The thing about AIDS deaths in Africa I hadn't heard anything about patents and the relation.
Your related point on home invention, I don't follow how that leads to patent system needing to be 'more violent'. If anything, it would largely be a return to what the patent laws were meant to protect in the first place. Corporations with large 'innovation portfolios' have the legal resources to probably have some half-decent protections in place through contracts and lawsuits in lieu of a patent system. The small home inventor has what effective means against protecting himself against being copied without patent system.
On discouraging collaboration, it's probably true to an extent, but companies do enter joint ventures to develop technology, under contracts that clearly define how any patent produced will be handled. Some companies will duplicate efforts if both have strong reason to believe they have a lead over the other. However, if two companies are neck and neck and realize either could get the breakthrough first, the odds a
Slashdot Mirror
By revoking a player's key that is being exploited to acquire title keys, *new* pressings of discs will not be susceptible until they figure out how to exploit another program that still has a valid key.
It's true, once the player's key is effectively compromised, any current disc that player can play is vulnerable, but new releases and new pressings of the current releases can be made unreadable by that player.
On the work backwards from a title key to the player key, I'm not sure I understand who you are asking about. I'm assuming you are saying how would they know which key to revoke. The answer is not based on the released keys, but on comments/watching the video. I think there are a grand total of two pieces of software currently, and one of them is used clearly in the video. In this particular instance, they know to take a long hard look at PowerDVD, but to be on the safe side, look at the other one and maybe revoke them both. The size of the market you have to piss off is very small at this point. If, say, 30% of the general population had a large variety of HD-DVD playback options, figuring out the key to revoke could be troublesome and piss more people off when/if they did.
Of course, if no player key is released, it remains a pain in the ass to play back an arbitrary disc, and, in fact, you *must* download the probably copyrighted title/volume key from the internet. Which means even in the absence of DMCA they can slap parties with distributing and downloading copyrighted material, even if they can't prove anything illegal with the actual movie content. It's essentially brought it up to the same level of pain in the ass as finding product keys for standalone software.
Here's the other part I don't understand about the described methodology. Someone said in a nutshell that the disc's keys are stored encrypted in all the players' keys. If each vendor has their own key, what happens 6 months down the road when a new vendor gets into the market, needs a key, and wants to play already released discs? Or have they already allocated a whole bunch of keys and not released them?
Looks like from his FAQ that he figured a deterministic way a particular piece of HD-DVD software stores the key in memory. Of course, it's always going to be the case the key is in memory during playback, finding the address would be the pain.. Wonder how he knew what to look for so quickly... Well, suppose he did have a couple of distinct movies, he probably had a set of addresses that obviously changed between discs or titles, and probably some tell-tale strings...
So he probably doesn't have the program's key (it would be in memory a short time probably if well implemented, but ultimately probably gettable, if the program can read it's own key, anyone can). However, expect content providers to audit how easily the key material is locatable in memory (i.e. how deterministic the key memory address is relative to program base address) and revoke keys in future pressings and force upgrades to software users.
Of course, with a few keys out it becomes problematic to hide the locations. Ultimately, the program has to know the offset to the key to use it, so there are going to be hoops to jump through, but using a known title with known key means the address of the key can be found and sampled over a few playback attempts, the memory address of the program analyzed to see if some pattern emerges or some variable points the right way....
BTW, if it was PowerDVD (which he never explicitly said), he is cocky actually showing that program running in his demonstration. PowerDVD is going to be under careful analysis now and his job will be made more difficult likely.
Of course, he could be more clever than I'm guessing, but the indications seem to be memory analysis of HD-DVD playback software.
Anyway, beyond making more hoops to go through, content providers cannot be so stupid as to think the problem technically insurmountable. It's all about demonstrating clear intent to violate DMCA and take legal rather technical measures to 'deal' with the problem.
Damn, I was redundant... I know that thought was echoing through almost everyone's heads on that one..
Whether it is a bribe or not-so-shady marketing is not a measure of the value, it's whether there are strings attached. However, shipping their own product is appropriate, shipping the laptop may not be a bribe outright, but it certainly is questionable.
If the recipient takes the gift talks about how shitty MS and Vista are, and MS can't take back their gift, it's not really a bribe. There is a logical assumption to make that such gifts would be less likely to occur if the reviewer doesn't do good by MS, and this opens the door to question bundling the laptop, but it technically remains not a bribe.
If the gift was contingent on a good review, it is certainly a bribe.
Now it becomes questionable because any good press coming from those who received laptops comes from those with a conflict of interest. If it had just been a free copy of Vista, and they didn't like it, they wouldn't be motivated to lie because all they have to gain are more free copies of a product they don't like. However by linking a laptop in, the reviewers may be inclined to look good to MS in the hopes of getting the laptops, even if they blow away the software on it after review because they truly thinks it sucks.
If the laptop vendor had sent the laptop, no big deal. After all, the reviewer only has to kiss ass of his favorite sample-providing vendor because the other products are inferior and he doesn't care.
I haven't had many problems in terms of longevity. Three of my systems did develop severe issues over the years, but invariably some fan in the system (1 chipset, 1 case fan, and 1 video card fan) had either stopped spinning or was spinning slowly and generating heat itself instead of mostly moving heat as it should. Replacing the fans resolved each problem. General rule of thumb is that if weirdness develops over time and persists through different OSes, hunt down bad fans and if you are lucky, no permament thermal damage has occurred. I had one motherboard blow capacitors, but that's usually a fairly hard failure, but you may want to check for non-flat capacitor tops. Aside from specefic capacitors, solid state devices tend to do well over time, so the likely culprit is some moving part (fan, hard drive).
I happen to buy almost entirely from Newegg (there is a local Tiger Direct outlet here, but they tend to be pricier than NewEgg. On the frontend I got motherboard, processor, RAM, and case/PS, so few interactions to go south, and few moving parts (3 fans). A system with a Promise SATA controller didn't work well with the sata_promise linux driver on the backend (concurrent IOs to multiple channels would knock the controller out of commision), so I bought a silicon image.
The SQL is generally transparent to the user, but sometimes granting privileges requires SQL statements be crafted/issued in a more complex backend/frontend config. Mainly I think they found it a convenient way to manage TV listings, and if requiring a DB, may as well use it. Also a natural way to share a config between backends and frontends. With only one mythbackend and some number of frontends, you don't need any file sharing to do the meat of mythtv.
Forgot some of the negative things.
First off, it was a moderate/somewhat hard effort for me. Keep this in context, though, as my day-to-day job involves putting together similarly complex net booting stuff, so diskless systems are old hat for me. Running X, booting it so it can sleep and be diskless, and doing it all in such a small amount of memory were challenges beyond the everyday (systems I work with rarely run X, never sleep, and always have gigs of ram). Myth itself is documented pretty well, but indeed has a lot of options and requires mysql to be running. For backend/frontend operation it's a little funkier and knowing SQL helps things, but guides are all over the place about that. So it will probably not be easy (I enjoy challenges, and learned a fair amount, particularly with the flexibility of trying different things I don't have the time to do at work)
Also, an ongoing issue is that mythtv 0.19 (haven't moved to 0.20 yet) forgets AV sync adjustments on seek. Related to this, some of my recordings end up ~500 ms out of sync from the beginning, for no discernible reason. The GeForce 6150 is up to a lot of tasks, but starts to choke on the level of ePSXe with the XGL2 GPU plugin (which is the most glitch-free, but demanding GPU plugin). The MesaGL plugin is fine, looks better (XGL2 renders to a texture and so aliasing is largely dictated by the resolution of the texture which is generally much smaller than your resolution, MesaGL renders direct to screen), but is subject to more glitches. Most gaming on this box is Mame/ZSNES/etc, so ePSXe is the most complex GL program I try to run. I have the games and a PSX and a PS2, but none look nearly as awesome as ePSXe at 960x720 (actually 1280x720 is the mode I select, but preserving aspect of course takes it down to 960x720 effective. Preserving aspect and using the full 1280x720 mode is the way to make it center on screen.) Also nothing beats the convenience of clicking on the games you want instead of media hunting and swapping.
The frontend is diskless, no hard drive or flash, netboots off the backend. I started with slax and heavily modified it so it runs off of a ramdisk root and nfs mounts most everything. I did this because it allows the box to sleep (ACPI S3) and resume despite being diskless. If I did nfs root, it couldn't access the utilities/libs to get the network straight again, usb flash disk similar story, it seemed that it wouldn't bring up usb good enough on resume, so ramdisk was my answer. The frontend, btw, was an Asus A8-VM CSM based system with 512 MB of RAM, if you want to know a system with sane enough ACPI to actually sleep under linux (with latest BIOS of course). If you splurge on 1 GB or more of ram, you don't even have to work to trim things down for the ram disk or putting it on nfs to get off the ram disk, and a vanilla slax with copy2ram would go a long way toward what you ultimately want. I really should write a howto somewhere, don't know where since I spent a fair amount of time getting everything to work without a disk and sleeping on a 512 MB ram budget and putting SLAX in a workable form to boot from tftp/nfs.. It was a lot of work, but I have a very quiet frontend with only fans as moving parts which don't need to ramp up much.
The backend has 4 250 gig drives in a software md5 and has the airstar HD5000 card in it (might recommend the new pcHDTV card which is basically the same thing, but the company is very explicit about the linux support. I use pcHDTV provided drivers for my card for some SNR/signal strength values, but am not convinced the formula for the pcHDTV is quite the same as HD5000... Anyway, the big advantages here are I have a huge case for the backend, lots of fans to keep things cool, and can keep it far from my frontend. My house has RJ45 drops everywhere, so I don't know first hand feasibility of 802.11g doing the job for less fortunate souls. 100 mbit is fine and HD content at 1.5x pitch shifted consumed no more than 35 mbit in my tests, but realistic 802.11g performance depends on your environment and I'm not sure what the feasible max or sustainable max is.
Anyway, I set up an analog set up before and a HD setup now. Keep in mind I only do over the air stuff with an antenna, cable and satellite complicate things beyond what I know. I have MythVideo to play DVDs and video files for cable-only or foreign content not licensed in the US (anything worth watching on cable ends up in a box set, is generally not HD on US cable channels, and it's cheaper to pick and choose that way given my watching habits). Setting up digital only, at least in the over the air case, was easier than the old way. The analog way you had to sweat the quality of your signal a lot more, and the quality of your tuner was more critical. Guys at work have cable and struggle with analog setups to get the quality of the capture nice and try out different cards (Cable company is far from all-digital, and encrypts a lot of the digital channels anyway) Digital your card simply has to have a comfy margin above the bare minimum, and copies the stream to disc, no subjective quality to worry about, you have exactly the data the broadcaster intended.
The backend if that is all it does, doesn't need much of a processor, but fast storage subsystem that is not heavily multitasked is a must. Don't have transcode jobs run when recordings are likely to happen concurrent, IO starvation could lose too much of the digital stream and cause bad artifacts. Playback during recording I haven't noticed problems.
The frontend needs to have a video card that supports XvMC, and/or a fairly nice processor. I have an Athlon64 1.8 GHz, which could do it without XvMC at 1.0x speed, but it cuts it close on some content. Plus, if the processor load is high too long the fans will start spinning faster. Pitch shift to 1.3x and some content will choke. The Asus I mentioned earlier has integrated GeForce 6150 and nvidia's drivers provide XvMC with it, and that drastically reduces the cpu load. Myth's wiki h
Live one calendar millennium ahead. Since you'll be dead then, you won't have any obligations!
Also lists resolutions, which top off at 720x480. Definitely not HD preserving, and likely no HD tuner. Of course, an HD tuner PCI card is about $100, so it may have put the vendor over their price point.
Doesn't take much to support 16:9. Also is effortless to support most sets with HDMI and distinct audio ports with a DVI-HDMI cable.
I have a diskless mythfrontend on my TVs HDMI port, running 1280x720, and the backend has an HD Tuner. Absolutely beautiful.
Admittedly, the subject didn't register with me, and yes, cygwin will give you some of the niceties of a *nix system in Windows. It is a good first step if you want to see what you think of *nix command line interfaces, but may be less interesting in terms of graphical applications which generally already have non cygwin Windows ports that work about the same anyway
He implied a new system purchase, and presumably this is a good time to give an alternative a spin. There are two parts to his question, really. The first and stated part is if there is benefit to be had to transitioning. The second part which is left unsaid but undoubtedly on his mind is what might he be giving up while in linux. On the first part, cygwin doesn't have nearly the software library a distribution would with apt or yum repo, so a lot of the benefits would be unrealized. The second part obviously you won't get a feel for unless you have an environment devoid of the crutch of Windows to fall back on.
Besides, FreeBSD you'd have to pit against a particular distribution if you want to exclude unofficial-like user contributed documents. Most distros nowadays have Wikis that cover pretty much whatever you want.
On the ports system, I've not tried Fedora since its inception, so I don't know how yum repoes are, but definitely gentoo portage and debian apt repos are nicely searchable (apt-cache or something like synaptic for GUI stuff). The ports tree was an impressive advantage, but now linux distros are out there that are even easier to pull and install stuff without compromising some of the benefits of binary package management (fast installs, ability to quickly determine which package owns a file, etc...)
On serious servers even before OSX/Ubuntu adopted the strategy, in shared admin environments the root password was frequently not set in my departments, to force admins to sudo and provide a better audit trail so you know who to ask about activity when.
There is very little you need the root password for if you have designated admin accounts permitted by sudo to do various tasks. The only complaint I heard from a new admin was 'what about single user mode', to which I would respond if they get such a prompt and need to actually do something, boot a rescue environment. The other objection I could think of which would be valid is if
This is not just a *newbie* thing to do. The bigger risk with having root a direct login is for people to get lazy and type root user/pass into a display manager login.
If the submitter never tries linux, how would they supposed to find out when it *would* be better for them? I think the description shows clearly he has reason (working with latex and python, and the platform is popular in the field he is working more into).
If they have the time and resources to evaluate a platform, particularly one that enjoys fair popularity in their field, they should do so.
In fact, I would recommend delaying a Windows license purchase on the new system entirely, unless transitioning his existing license from his old desktop. Leave Windows on the older system and see if Linux can fit the bill more than he realizes. Windows is not free by any legal measure, so already there is benefit migrating to a free platform and save a fair chunk of money (even XP home OEM is 90 bucks right now)..
Not recommended, the goal is clearly to be a university or similar workstation/server, adding AFS configuration and such as they repackage RHEL. Not a large community/yum repo, and not oriented to new users without competent administrators to complement them.
Debian and debian derivatives by far have the most rich environment and repositories. I haven't tried Fedora Core except a couple of times briefly, but by now they may have a fair yum repository.
I started with linux kernel 1.2.3 (was easy to remember) on a slackware distro back in the day.... ah the memories....floppy after floppy after floppy....
No thanks. I grew tired of dealing with obscure broken library dependencies on upgrades on my *own* systems, sure as hell don't want to have to answer someone who, in the process of emerge -upv world (or whatever it is anymore), ended up with applications linked to libraries with changed versions. I know there are utilities to automatically run ldd against everything (revdep or revbuild.. can't remember) and re-emerge, but in the end, big pain in the ass, and ultimately you don't learn that much more about linux like, say, doing a linux from scratch would teach if that were the goal.
Definitely would go with an Ubuntu install. Debian would also do the trick with little hand-holding, but at times Ubuntu is more practical about some packaging decisions while Debian can be more purist. Also, Ubuntu clearly targets a set environment, and Debian endeavors to make sure everything works pretty well, but expects the user to know more about what they want to make choices for themselves. Also, Ubuntu is easier to showcase the newer stuff typically (though Debian Etch and Ubuntu Edgy are about equivalent on that front currently).
I know what dd is, I was thinking you were implying dd was needed to extract cpio, but I realize you were just talking about doing rpm2cpio manually with dd.
I don't think the format of having a header that can be parsed without extraction is a bad thing, so long as the header provides all the functionality needed, which rpm does not.
But is it merely trying to get Mac apps to compile and run, or actually duplicate the whole user interface paradigm? Honestly speaking, the ability to simply run Mac apps isn't exciting, for the most part we already have good equivalents. It is appealing to use those projects under GNUstep because they were designed with that sort of user interface in mind unlike GTK/QT apps, but the applications in and of themselves have no features not implemented in the counterparts.
Well, to be more accurate, they cared about NeXT enough to base OSX off of it. GNUstep is the most API-compatible option that can run on alternative platforms. Of course, its not because of the API that it is so interesting as a desktop platform, and developers and users have come to appreciate it in OSX.
.nfonts). Also GNUstep could probably accomodate more of the freedesktop specification than they currently do, however I do recognize that freedesktop specifications pretty much have the MS way of doing things in mind and therefore some things aren't appropriate for GNUstep. Also, GNUstep doesn't have a perfect window manager to use with it. WindowMaker is very good, but doesn't render menus/dock in a way that is guaranteed to be visually consistant with GNUstep. WindowMaker is probably the best effort to focus on moving forward, but there is work to be done.
The two main open desktop projects (GNOME and KDE) heavily mimick the user interface paradigm established by MS. GNUstep is a good complement with the NeXT (also OSX) user interface paradigm (separate menu, management of windows individually and by application, applications registering services for more complex/powerful gui actions than what is done by drag/drop, copy/paste, etc).
GNUstep/NeXT/OSX services are the only appropriate equivalent of command line pipes in GUI land, which makes it a highly logical fit for those who understand the beauty and power of pipes in *nix. For example, in Gnome/KDE if an application wants spell check, they need to implement it themselves or at least take in a library and hook things around it. In GNUstep, any text application I can highlight something, click services/spell check if I have a spell check app installed, and it will happen. People complained for a long time about browsers not having spellcheck, but with services implemented and used browsers would have had it for free. It's kinda like piping the output from some command into aspell. All kinds of interesting things have been done with services, and someone implementing something new and different ends up enhancing all the desktop software that is appropriate for it without extra effort.
I have used GNUstep many a time to see how they are going, and if the environment were more complete (i.e. a GNUstep web browser, and IM client, office software) I would use it as my desktop full time. I remember before gcc had objc++ and before gnustep & gorm had nib support, that those two barriers going away was expected to allow all kinds of wonderful porting from OSX (i.e. the OSX Firefox code, one of their IM clients, whatever else). I haven't seen any word on efforts since those developments. I would love to contribute, but my plate is too full.
The downside is that in GNUstep more so than KDE/Gnome, non-native applications are really jarring, without separate menu and not interfacing with services. WindowMaker does a good job grouping windows by application for application hiding, but it isn't enough. Also GNUstep is capable of doing a lot, but fonts, for example, are a pain in the ass (at last check with the decent backend with anti-aliasing you had to package fonts in
If you work it, GNUstep is a lot further along than most people realize, but the fact you have to work hard to get a complete environment discourages new users. And even when all is said and done, things are a bit rough around the edges in spots...
Right now the cost/benefit analysis of any medical research strongly favors treatments over cure. If investors see two projects with two possible outcomes, one with an expensive and inconvenient regimen for the rest of someone's full life, or a project that plans to have a 30-day cheap pill cure, the investors will lean toward the one *obviously* suboptimal for society, because ROI is higher.
If something like what you are talking about is done, more measures can be taken to level the playing field so that cures are financially as well as socially are better than treatments.
the less proprietary x86 architecture that took the market by storm in spite of it's design flaws.
Largely because IBM didn't realize what they were doing with the platform and MS. IBM's funding largely launched the platform using a large R&D buget, and a host of companies that would have been unable to otherwise get into the market latched on and largely undercut IBM (IBM's pricing reflected having to recoup R&D, which competitors didn't have to as directly. The irony of your example is that IBM allowed it in part due to patents. Back then to a large extent and today to a lesser extent, implementing an x86 PC involves on various levels paying IBM license fees to use patented strategies. IBM would *not* do the R&D needed for things to happen like the PC revolution without patent protection. If they had no legal recourse to protect their invention, they would either not risk the investment or otherwise find ways of making it near impossible to reverse engineer and keep the secrets tight and never license them out. Same with your example, you look at the current state of things, stating how freeing the patents would create a wonderful free market for existing research, but fail to demonstrate how big R&D budgets would be risked by companies if they know they are just going to be ripped off and undercut when the no-R&D company copies it.
Inventors are good at inventing things, so patents do really not help inventors or small lean innovators
Huh? I guess you are trying to say inventors have nothing to fear because they have plenty of ideas to go around? Again, oversimplifying (one could have one single brilliant idea), but even if accepted, it doesn't help. If you have a thousand ideas, and each takes 100 dollars worth of work to work the details into a marketable way, and at the end of the day, a guy can copy your idea with 10 dollars of effort per idea, when you get to market you will compete with someone who had 10% of the development costs to recoup that you do. The problem is not that invention is needed, it's that invention that costs non-trivial amounts in R&D to achieve becomes impractical due to the market realities of competition.
The point about violence inherent in the system (had to slip python in) seems kinda ludicruous. Never heard of violence-enforced patent situations. Automobile safety tech was not held back because of patents, they just didn't want to do it until the government forced them to. If government directly would not have, the increasingly litigious society probably would have forced the issue, but I digress. DDT was banned not because of patent expiration, but because they didn't understand the implications until then. Plenty of such things have been banned by the government well before patent expiration. Freon similarly was part of the 80s environmental push, the timing coincides with too many other regulations to have them all be tied to freon patents. The thing about AIDS deaths in Africa I hadn't heard anything about patents and the relation.
Your related point on home invention, I don't follow how that leads to patent system needing to be 'more violent'. If anything, it would largely be a return to what the patent laws were meant to protect in the first place. Corporations with large 'innovation portfolios' have the legal resources to probably have some half-decent protections in place through contracts and lawsuits in lieu of a patent system. The small home inventor has what effective means against protecting himself against being copied without patent system.
On discouraging collaboration, it's probably true to an extent, but companies do enter joint ventures to develop technology, under contracts that clearly define how any patent produced will be handled. Some companies will duplicate efforts if both have strong reason to believe they have a lead over the other. However, if two companies are neck and neck and realize either could get the breakthrough first, the odds a
That is crazy, everyone knows that 0.001 m is the same as 0.001mm, if you look at it on paper...