Surely your toaster and coffee maker don't need 32nm? Wouldn't it be great to have all the parts that aren't CPUs down to 60nm without the costs associated with 60nm lithography?
Let's see, drive electronics, sound processors, Ethernet controllers (the ones that aren't on your southbridge), microcontrollers, any kind of embedded chip... There are lots of things that aren't 65 nm yet, or even at 90nm, and some chips aren't 130nm for that matter. Wouldn't it be great to get things that are currently larger down to CPU-ish feature sizes?
Just think of all the things these specialty chip designers (the ones with SSL accelerators, AES on-chip, vector processors, Forth chips, Java chips, etc) could do if they could get down to 60nm at or near FPGA prototyping prices. Hell, the Via C7 getting down from 90nm to 60nm would be great. Companies like Transmeta might bounce back into chip production. ARM9 is currently at 130 and XScale is 180. Getting those down to sizes that match Intel and AMD's current or even last-gen products at far less cost could give us really powerful handhelds.
That equation, of course, should say '3 * 44 + 80 = 212'. I'm pretty sure I did a preview, too, but I didn't notice that until looking back at it later.
And I suppose the wait staff who are glad to be working in this restaurant because it's some form of work and the tips are decent are free to just not work at all if they don't want to inhale the fumes, too?
There are always people working in restaurants and bars. They don't always have the choice to work in smoke-free establishments in places where the establishments can choose to allow smoking.
If you worked in a factory that released carbon dioxide, carbon monoxide, hydrogen cyanide, benzene, formaldehyde, ammonia, acetone, arsenic, and particulate matter into the air to the point of causing many people to cough and wheeze, you'd better bet the factory owner would be in shitloads of trouble with OSHA or some other agency. Yet cigarettes put out all of that, and so many people think it's great that people with high-school or eighth-grade educations get to choose to wait tables around it so that they can be free to kill themselves slowly in a public place.
At the least, restaurants and bars that allow smoking should have to have air quality checks, feature MSDS sheets on the chemicals in cigarette smoke, and pay for illness related to second-hand and third-hand smoke inhalation for the workers and the workers' families. Workers who choose not to work around cigarette smoke should get whatever unemployment or welfare benefits they'd otherwise be qualified to get if they turn down work around cigarette smoke.
All of this is only equal to what other workplaces already must do regarding hazardous airborne chemicals in the US, but restaurants seem to get some special pass on cigarettes and often also hazardous cleaning solutions. If you're for allowing smoking base don the owner's rights, does that mean that we should do away with all labor safety regulations and laws?
Does your system with four CPU cores have four or more fast disks? Lots of the problems I hear about with IO being slow is that people put two, four, or eight cores into a machine, knowing that their one disk will be the bottleneck. Sure, four or eight disks will still be a bottleneck, but not as much.
How much is your four-core CPU? You can buy a nice Seagate SATA 3.0Gbps PRT 320GB disk for for less than $80 on NewEgg. Ideally you could buy twelve, and set up four RAID 5 arrays. Assign one array to be/usr and swap, one to be/home, one to be/var, and one to be/tmp. Alter this scheme as fits your special needs, of course. 12 * $80 = $960. You'd probably also need an extra SATA adapter card unless you're running one hell of a server board.
If that's too steep to go along with your underutilized $500 processor, maybe just get four for $80 and use single drives vs. arrays. That's $320 and is only a bit more than the cheapest Core 2 Quad.
Of course, you could go even cheaper and use 40GB for/usr and swap unless you're some kind of software collector. You could probably also do with that much for/var and for/tmp for that matter. So get 320 GB for/home, and 40 GB for each of the others, and save a bit more. If you want to stick with the 7002.10 series for the perpendicular recording, the 80GB drives are about $44. So 3 * 44 = 80 = 212.
$212 dollars worth of disks to speed your reads and writes significantly if you're using a single disk. Or even reuse the single disk for/home and make it a $132 investment.
Of course, this doesn't include shipping or power costs. But you get the idea. You can speed your machine's IO up quite a bit by having more than one disk. It's not just that you're talking about four times the transfer speed, either. You're cutting down on seeks, missed read and write opportunities, cache contention, and command queue length by going to more drives on separate interfaces. On lots of machine workloads, such as a heavily trafficked file server or mail server with local logging, you can, IME, get a machine to handle up to about four times the workload by separating the data and the logging onto separate disks.
If you want sufficient evidence that you thought of something by a certain time, get it published in a magazine, newspaper, or such. Who's going to argue that your plans and concept aren't prior art when they're in Scientific American, Wired, Dog Grooming Monthly, or Fast-food Mexican on the Cheap Magazine before someone else starts using the idea?
If by "used to reading papers like this" you mean people who don't also (and primarily) read papers from computer industry and computer academic sources, maybe.
In the computer field, it's not uncommon to read an 400-page book on a topic that leaves dozens of things for treatment elsewhere. There's no sense in trying to sell an untargeted 9600-page book when your author and editor have produced 400 pages of meaningful, focused content. Of course, this also falls under your "other circumstances", but it's no maybe.
Didn't the VH1 segment Viacom produced use his full segment?
Viacom never held a copyright on the derivative of his work if what they made is considered an unlicensed derivative. That's what his copyright means -- they can't distribute those, and have no ownership rights in them because they are derivative works.
He can, as fair use, use up to so many seconds of anything in order to comment on it.
OTOH, it seems YouTube makes users allow YouTube/Google the right to make derivative works and to allow them to license that right. Check out YouTube's TOS, particularly section 6C. It's possible Viacom paid Google for the right to show this segment.
That is one reason for something to be beyond the scope of paper. Another is that the paper has already hit the publisher's word limit. A third is that the topic at hand has been narrowly discussed for clarity or for time restraints on the project. A fourth is that the paper could become unwieldy if tangential topics are included.
It could be a combination of any or all of those. "Further research is needed to determine why this is so" is not so vague, and could be used if that was the exact meaning intended.
Viacom doesn't own the clip made from his clip because it's a derivative work of his clip. A commentary is not enough for them to claim fair use of his entire clip. The only part they might be able to claim copyright on is their commentary.
He then used their commentary along with his own copyrighted content, so that's fair use of their commentary.
IANAL, but there seems to be copyright infringement, attempted misappropriation of copyright, and a fraudulent DMCA take-down notice all coming from Viacom.
The angle MS and Novell are taking is that Microsoft's vouchers apply to Novell's GPL v2 stuff. If Novell just happens to distribute GPL v3 stuff in place of that, then it's Novell distributing it of its own free will and not a procurement via Microsoft.
I say the FSF has a right to question that tactic. I'm just not sure where the courts will fall on it.
What copyright is being infringed by making calls on another network? Why does the DMCA have anything to say about soldering an desoldering to achieve network independence?
If they use a symmetric key cipher on the data itself, that does complicate things a bit.
If they use the passphrase itself as the key for the symmetric cipher, though, you have a short set of text the user can easily remember running against hundreds of megs of plaintext. The resulting crypted text would have all kinds of patterns in it.
It could be made better by having the passphrase run against a larger key. Your 10 to 20 character passphrase encrypts a 1024-bit key (which is only 128 bytes). Then, that could be used to encrypt the files, preferably in a chaining block cipher organization per file. If you can stand the space overhead a new 1024-bit random key embedded after every 1024 bits of plaintext and encrypted with the previous key would be nice, but CBC is generally considered good enough without the space overhead.
Of course, if someone has intermittent physical access to your stick, they'd just patch the part that moves the decrypted data across the USB connection (or, if the decryption takes place on the PC, they could do it in the driver). Even easier, given physical access to the PC where you use the stick, would be to just patch the OS or put a memory sniffing program onto the PC where you're working with the plaintext anyway.
In this particular instance, the passphrase being replaced by a fingerprint scan, one only needs enough physical access to store the pattern the thing makes from your fingerprint so they can resubmit it to the authenticator the next time around. You probably won't be changing your fingerprint once a month, so this gives them possibly unlimited access in the future even if you're continuing to use the device. A fingerprint and passphrase both are the only way to improve on this.
Oh, and one of the technical challenges to using the passphrase itself to encrypt the whole data store is that every time you change the passphrase, you need to decrypt and re-encrypt the whole store. That's some nasty overhead. Just decrypting and re-encrypting the 1024-bit key I mentioned earlier would be much more plausible.
Like anything that's secured in software, the security is a joke when someone has physical access to the device. If it can be done in software, it can be bypassed in software given the chance to tweak or replace the binary.
I do not mandate planning for "the OSS community". I do not represent or speak for "the OSS community". I'm one person.
I never said it's necessarily better than it seems from those numbers. I only said it's not clearly as bad as some are trying to say those numbers mean. There's a big difference.
I'm not sticking my head in the sand, and I never suggested anyone else does.
If your incitement represents your understanding, then no, you do not "understand it right [sic]".
I don't have to adapt to anything. I'm not an Apache developer nor a Linux developer. I don't market nor sell those two projects. I do perform and contract to perform services which utilize those packages, but IIS gaining some market share does not diminish my ability to do so. Only if Linux and Apache go away (actually, only if Apache went away, as most of my stuff runs just as well on Solaris, BSD, and yes, even Windows) completely does it matter materially to my business. Both Apache and IIS growing at the expense of other web servers and in response to general growth of the market is not a sign of Apache going away.
While some in the OSS world do have an "us vs. them", "winner takes all", and/or "only my choice" mentality, that's far from the whole "OSS community", if such a broad label really carries much meaning at all. My favorite quick-snippet descriptions for OSS are "only the best craftsmen invite inspection" and "quit pissing in my pool".
OSS gives me a chance to see what I'm running and possibly fix it. In those cases I don't have the time or the skill to fix something, it at least gives me the chance to listen to the advice of skilled people who have access to the source. Many of them will fix things and share the fixes. I don't like putting crappy software on my systems that make diagnosing problem hard and fixing them harder or impossible. Messes do hide in Open Source software, but not for as long nor as easily as in closed source software. Locksmiths, doctors, auto engineers / mechanics, security experts, research scientists, mathematicians, and more publish what they've accomplished for review and use by others. Why shouldn't computer scientists, software designers, and programmers?
If I find closed-source software that's stable, does what I need it to do, and is flexible enough to keep doing what I need it to do, then I have no problem with paying a fair price for it and letting the developers keep it closed. It upsets me that so many companies expect hundreds or thousands of dollars from customers for buggy, unstable, insecure, inflexible messes that don't ever get fixed. If someone wants their software on my system, they won't let their software devalue my investment in my systems. The software should always add value, or otherwise why did I pay for it? That's what I mean by pissing in my pool. Some closed-source vendors don't do that, but too many do. OSS projects might suck, but if I'm not paying for the program then it's no loss to replace it with something else. If I'm paying for support, earlier access to new features, or something like that, those are things I'm choosing to buy. The source code that almost does something right even has inherent value over that of a closed binary that does the same thing. The developer or vendor of that Open Source code is being better to me and treating my systems with more respect than the closed-source vendor.
Open Source is sometimes considered a political movement. I think it's really more of a philosophical one. There's more than one way to make a buck in software development. There are probably fewer ways to really make significant progress in software development. Peer review and public comment seem to help quite a bit, and that's what's more important to most people than RMS's statements or any of the other manifestos.
A sysadmin's job is productive when you don't need to do the things that show you've not been productive. That's an awkward wayto say something that most admins already understand, so let me explain.
If you're researching new software, running performance numbers on new hardware before putting it in production, testing boxes, upgrading systems, patching systems, monitoring systems, rotating logs, etc, you're generally doing a pretty good job.
If you're fixing problems in production after they happen, coming in to the beeper because you don't have sufficient fail-over to last until morning, yelling at your hardware vendor that you need your expedited shipping even more expedited because your system utilization outstripped your expectations and your fudge factor, and basically "fighting fires" and reacting to problems rather than planning for them and preventing them, you could do better.
Measuring productivity of a sysadmin is a somewhat silly concept, really, because a sysadmin doesn't produce anything. A sysadmin is a manager (used to often be called "system manager" in fact), and "administrator" should be a sign of that. The fact that your resources are technological and not employees makes no difference. It is not your job for you to produce anything nor to be productive in any way.
Your job as a sysadmin is to make sure those you manage are productive. Hence, "production systems".
You could base your metrics on how many machine hours at what utilization you're getting out of your hardware and software. One way is the "useful utilization" metric. If you have ten production systems load balanced and one testing system that represents that configuration in tests, and you're running 90% utilization of the most limiting resource on those systems (CPU, memory, disk I/O, etc), then you're getting 90% productivity out of production servers and 81% productivity overall. Try to find another department in your company that runs at 90% average theoretical efficiency. If half of your systems are down on any given day of a week for four hours apiece for one reason or another, that's 4 * 5, or 20 hours out of your 168 * 10, or 1680 hours, times 0.9 (for the 90% utilization). That brings you down to about 87% on the production servers.
Another good metric I suppose is client requests served per dollar (yen, yuan, peso...) of hardware, software, and power investment. If you can figure out a dollar value of the average client request in some way, that can even point you towards ROI for the systems. A good sysadmin has a higher ROI from his systems than a poor one given the same hardware and software, after all.
I guess you could try to measure the admin by hours spent in proactive work vs. hours spent in reactive work. A good ticketing system could make this pretty trivial to track. However, if the standard ticket resolution is to power cycle a whole rack, this makes a very bad sysadmin look stellar. You'd also have to have a ticket queue and resolution tracking on research, upgrades, patches, server purchases, requisition writing, and other things which typically don't get tracked as closely as problem reports.
There's a popular idea that when anything on a public forum like Slashdot might be harmful to certain parties, this sort of sexual blather gets put in the thread so that porn and obscenity filters keep it out of many hands. Microsoft is the usual suspect, and the parent of the sex blather is questioning the effects on MS's EULA.
I'm not drawing any conclusions here, and I don't think anyone should at this point. It is an interesting theory, and this would be a prime example if it's true.
Assuming you're using waste heat from another process to bring the water to HTE temperatures, you actually do get more productive energy out of the hydrogen than the energy used to break the bonds with the oxygen. That waste heat is energy input, but it's energy that wasn't being used for anything before. Please read up on the process. It's not a cure-all, and it's not perpetual motion. It is very interesting.
Of course if someone is creating the heated environment only to perform steam electrolysis, that'd be a pretty inefficient way to do it. There are lots of processes we already use that create the necessary 300-700 degree C steam, or the potential for it. If by harnessing this wasted energy we can get a net gain on the electricity needed for the electrolysis, that's a win.
A for biofuels, I agree they are at least a good stopgap measure. They are better for not just chemical and ecological reasons in some ways, but they could be very helpful in the political and economic arenas within certain countries and internationally. Unfortunately, they also have some nasty limitations and side-effects of their own. Ethanol is much harder to transport than most forms of petrochemicals because of the types of materials needed to safely transport it. The best sources of ethanol from plants would appear to all be as geographically limited as oil, only in mostly different countries. Ethanol and biodiesel are currently largely being made from food crops, which can be a big drawback. There have been some promising results with biofuels from other sources, such as methanol from livestock farms and from algae-laden sewage treatment, but those haven't become reliable or mass-produced as of yet. Noone knows for sure how viable they may become. Burning biomass directly and using steam turbines, tapping landfill gas, burning latrine/septic tank methane, and more are possible, but each has issues. All in all, there's a lot of promise and a lot of caveats.
One of the biggest things we can do to help the situation is to go to more localized electrical generation, as we lose a great deal of efficiency through resistance and impedance in, for example, the North American power grid. It's odd that so few people make an issue out of that.
Pebble fission reactors might be the only well-proven technology we have that's able to be close to a single solution in the near term (rod-style reactors being relatively dangerous and ill-received) and uranium isn't really a renewable resource, either. Then there's the waste.
Essentially, we live in a time of great uncertainty about energy. There's likely not going to be one power source as dominant as petroleum has been, but I guess it's possible. After all, cars were once run on coal or wood steam engines, coal dust burned internally, kerosene burned internally, alcohol, kerosene steam engines, and even electricity before gas and diesel became standard enough to narrow the field. Homes were and often now are powered at least partly by natural gas or even wood. Alcohol, kerosene, and coal used to be popular for lights and heat as well. There's a possibility we'll see just a handful of power sources shine through again, but there's a great chance we'll be weighing how two products are powered along with other features when making buying decisions.
It is _almost_ possible. You're not putting any energy into the hydrogen through electrolysis. You're simply breaking the molecular bond it has to the oxygen. The oxygen is then released and not stored. Then, you're burning the hydrogen with atmospheric oxygen and producing water vapor, which gets released and not stored. There is waste in the heat and the friction, so you do lose some energy. You get most of it back because both processes are pretty efficient. HTE is even more power efficient than low-temperature electrolysis, especially if you already have a source of heat (nuclear, a blast furnace at a cement plant, geothermal, etc).
You would need additional energy inputs to the electrolysis stations besides just hydrogen, and that could be done with wind, solar, tidal, geothermal, and nuclear. Assuming you're using just regular grid power to produce the hydrogen from water, though, you could be burning hydrogen at one location to produce it at another.
So yes, I oversimplified. My point is, it doesn't matter where you get the electricity for purposes of this discussion. There is a shortfall if you use only hydrogen to get the hydrogen, but it's no different than if you use only petroleum to drill, pump, refine, and transport petroleum. Large central hydrogen fusion plants that electrolyze steam along with smaller hydrogen production facilities using grid power or other power sources more than handle the demand if implemented satisfactorily.
We always live, at some scale, inside a sealed system. Solar seems renewable enough, but once our sun is gone, it's not coming back. Figuring out where one gets the additional energy into the system is _always_ an issue, even for biofuels.
Okay, I read a cache of the article. It doesn't answer any questions about what might not be stock Ubuntu 6.06, but simply assumes that uname/motd says it all.
Another option for a perfectly secure box that wasn't mentioned in TFA is that the friend could have run a Trojan that opened the initial hole.
Okay, I've not yet RTFA. Did it specifically say, "bog standard Ubuntu 6.06 with absolutely no additional software and only bare necessary configuration changes needed for system differentiation purposes"?
I ask because everyone seems to be looking very closely at the initial OS distro, and almost any server that's been put into useful production has been tweaked in some way from the official packages. Stuff gets compiled from source. Custom stuff gets coded. Packages get installed out of third-party repositories or straight from vendor sites. Daemon configurations get changed, firewall rules may be tweaked, and additional modules for existing server daemons get added.
Hell, they could have done something as stupid as allowing root logins through unencrypted telnet, then actually using that "feature".
Oh, well, off to RTFA to see if it contains any of the answers.
Burning hydrogen in an ICE gives you more power than it takes to separate it out of water. So you burn hydrogen to get the power to separate out more hydrogen from water. The problem is, if we're so concerned with crops because we're using the crops for other things, why aren't we worried about the crops because we're using the water for other things? You'd also be using hydrogen production that is also being used to create ammonia for fertilizers for the crops.
Yeah, you can electrolyze seawater, but when you take the seawater out of the sea and burn the hydrogen in cities and the rain falls near there rather than letting it evaporate at its normal rate from the normal places, you're changing weather patterns just as surely as with greenhouse gases.
You get better efficiency from hydrogen fuel cells than from burning hydrogen, but the cells are more expensive to produce and replace than ICEs. Fuel cell grid plants and vehicles might still be a better option than ICE or turbine ones. Pure electric vehicles are more efficient still, but then you have the batteries, the charging delays, etc.
Hydrogen ICE cars with small fuel cells for the electronics (so you're not burning it just to turn a generator with part of it) or completely hydrogen fuel cell powered cars may be a good balance between efficiency and range, as one can refuel hydrogen much faster than one can recharge batteries, and hydrogen (while dangerous in its own right) is probably safer in the long run than most battery technologies.
Oh, you'll get plenty of work out of a teenager on a sugar rush. It just won't necessarily be the work you asked him to do, and might not have any useful end result.
Slashdot Mirror
Surely your toaster and coffee maker don't need 32nm? Wouldn't it be great to have all the parts that aren't CPUs down to 60nm without the costs associated with 60nm lithography?
Let's see, drive electronics, sound processors, Ethernet controllers (the ones that aren't on your southbridge), microcontrollers, any kind of embedded chip... There are lots of things that aren't 65 nm yet, or even at 90nm, and some chips aren't 130nm for that matter. Wouldn't it be great to get things that are currently larger down to CPU-ish feature sizes?
Hell, Intel's 82598 dual-port 10 gigabit Ethernet controller is 90nm. If they could make it 60nm on the cheap, that'd be great.
Just think of all the things these specialty chip designers (the ones with SSL accelerators, AES on-chip, vector processors, Forth chips, Java chips, etc) could do if they could get down to 60nm at or near FPGA prototyping prices. Hell, the Via C7 getting down from 90nm to 60nm would be great. Companies like Transmeta might bounce back into chip production. ARM9 is currently at 130 and XScale is 180. Getting those down to sizes that match Intel and AMD's current or even last-gen products at far less cost could give us really powerful handhelds.
That equation, of course, should say '3 * 44 + 80 = 212'. I'm pretty sure I did a preview, too, but I didn't notice that until looking back at it later.
And I suppose the wait staff who are glad to be working in this restaurant because it's some form of work and the tips are decent are free to just not work at all if they don't want to inhale the fumes, too?
There are always people working in restaurants and bars. They don't always have the choice to work in smoke-free establishments in places where the establishments can choose to allow smoking.
If you worked in a factory that released carbon dioxide, carbon monoxide, hydrogen cyanide, benzene, formaldehyde, ammonia, acetone, arsenic, and particulate matter into the air to the point of causing many people to cough and wheeze, you'd better bet the factory owner would be in shitloads of trouble with OSHA or some other agency. Yet cigarettes put out all of that, and so many people think it's great that people with high-school or eighth-grade educations get to choose to wait tables around it so that they can be free to kill themselves slowly in a public place.
At the least, restaurants and bars that allow smoking should have to have air quality checks, feature MSDS sheets on the chemicals in cigarette smoke, and pay for illness related to second-hand and third-hand smoke inhalation for the workers and the workers' families. Workers who choose not to work around cigarette smoke should get whatever unemployment or welfare benefits they'd otherwise be qualified to get if they turn down work around cigarette smoke.
All of this is only equal to what other workplaces already must do regarding hazardous airborne chemicals in the US, but restaurants seem to get some special pass on cigarettes and often also hazardous cleaning solutions. If you're for allowing smoking base don the owner's rights, does that mean that we should do away with all labor safety regulations and laws?
Does your system with four CPU cores have four or more fast disks? Lots of the problems I hear about with IO being slow is that people put two, four, or eight cores into a machine, knowing that their one disk will be the bottleneck. Sure, four or eight disks will still be a bottleneck, but not as much.
/usr and swap, one to be /home, one to be /var, and one to be /tmp. Alter this scheme as fits your special needs, of course. 12 * $80 = $960. You'd probably also need an extra SATA adapter card unless you're running one hell of a server board.
/usr and swap unless you're some kind of software collector. You could probably also do with that much for /var and for /tmp for that matter. So get 320 GB for /home, and 40 GB for each of the others, and save a bit more. If you want to stick with the 7002.10 series for the perpendicular recording, the 80GB drives are about $44. So 3 * 44 = 80 = 212.
/home and make it a $132 investment.
How much is your four-core CPU? You can buy a nice Seagate SATA 3.0Gbps PRT 320GB disk for for less than $80 on NewEgg. Ideally you could buy twelve, and set up four RAID 5 arrays. Assign one array to be
If that's too steep to go along with your underutilized $500 processor, maybe just get four for $80 and use single drives vs. arrays. That's $320 and is only a bit more than the cheapest Core 2 Quad.
Of course, you could go even cheaper and use 40GB for
$212 dollars worth of disks to speed your reads and writes significantly if you're using a single disk. Or even reuse the single disk for
Of course, this doesn't include shipping or power costs. But you get the idea. You can speed your machine's IO up quite a bit by having more than one disk. It's not just that you're talking about four times the transfer speed, either. You're cutting down on seeks, missed read and write opportunities, cache contention, and command queue length by going to more drives on separate interfaces. On lots of machine workloads, such as a heavily trafficked file server or mail server with local logging, you can, IME, get a machine to handle up to about four times the workload by separating the data and the logging onto separate disks.
If you want sufficient evidence that you thought of something by a certain time, get it published in a magazine, newspaper, or such. Who's going to argue that your plans and concept aren't prior art when they're in Scientific American, Wired, Dog Grooming Monthly, or Fast-food Mexican on the Cheap Magazine before someone else starts using the idea?
If by "used to reading papers like this" you mean people who don't also (and primarily) read papers from computer industry and computer academic sources, maybe.
In the computer field, it's not uncommon to read an 400-page book on a topic that leaves dozens of things for treatment elsewhere. There's no sense in trying to sell an untargeted 9600-page book when your author and editor have produced 400 pages of meaningful, focused content. Of course, this also falls under your "other circumstances", but it's no maybe.
Didn't the VH1 segment Viacom produced use his full segment?
Viacom never held a copyright on the derivative of his work if what they made is considered an unlicensed derivative. That's what his copyright means -- they can't distribute those, and have no ownership rights in them because they are derivative works.
He can, as fair use, use up to so many seconds of anything in order to comment on it.
OTOH, it seems YouTube makes users allow YouTube/Google the right to make derivative works and to allow them to license that right. Check out YouTube's TOS, particularly section 6C. It's possible Viacom paid Google for the right to show this segment.
That is one reason for something to be beyond the scope of paper. Another is that the paper has already hit the publisher's word limit. A third is that the topic at hand has been narrowly discussed for clarity or for time restraints on the project. A fourth is that the paper could become unwieldy if tangential topics are included.
It could be a combination of any or all of those. "Further research is needed to determine why this is so" is not so vague, and could be used if that was the exact meaning intended.
Bullshit.
Viacom doesn't own the clip made from his clip because it's a derivative work of his clip. A commentary is not enough for them to claim fair use of his entire clip. The only part they might be able to claim copyright on is their commentary.
He then used their commentary along with his own copyrighted content, so that's fair use of their commentary.
IANAL, but there seems to be copyright infringement, attempted misappropriation of copyright, and a fraudulent DMCA take-down notice all coming from Viacom.
- They must include a copy of the license.
- They must provide a written offer with the package to provide the source on request.
- They cannot strip attributions in what they provide
I don't know that they've done the last one, but it makes sense along with the other violationsNo, they'd have to sue themselves! 10.0.0.1 is on their network. They can tell by the fact it doesn't get past the router to the ISP.
10/8, 172.16/12, 192.168/16, and 127/8 all should be on the network of the people checking for them, if they seem to exist at all.
The angle MS and Novell are taking is that Microsoft's vouchers apply to Novell's GPL v2 stuff. If Novell just happens to distribute GPL v3 stuff in place of that, then it's Novell distributing it of its own free will and not a procurement via Microsoft.
I say the FSF has a right to question that tactic. I'm just not sure where the courts will fall on it.
What copyright is being infringed by making calls on another network? Why does the DMCA have anything to say about soldering an desoldering to achieve network independence?
If they use a symmetric key cipher on the data itself, that does complicate things a bit.
If they use the passphrase itself as the key for the symmetric cipher, though, you have a short set of text the user can easily remember running against hundreds of megs of plaintext. The resulting crypted text would have all kinds of patterns in it.
It could be made better by having the passphrase run against a larger key. Your 10 to 20 character passphrase encrypts a 1024-bit key (which is only 128 bytes). Then, that could be used to encrypt the files, preferably in a chaining block cipher organization per file. If you can stand the space overhead a new 1024-bit random key embedded after every 1024 bits of plaintext and encrypted with the previous key would be nice, but CBC is generally considered good enough without the space overhead.
Of course, if someone has intermittent physical access to your stick, they'd just patch the part that moves the decrypted data across the USB connection (or, if the decryption takes place on the PC, they could do it in the driver). Even easier, given physical access to the PC where you use the stick, would be to just patch the OS or put a memory sniffing program onto the PC where you're working with the plaintext anyway.
In this particular instance, the passphrase being replaced by a fingerprint scan, one only needs enough physical access to store the pattern the thing makes from your fingerprint so they can resubmit it to the authenticator the next time around. You probably won't be changing your fingerprint once a month, so this gives them possibly unlimited access in the future even if you're continuing to use the device. A fingerprint and passphrase both are the only way to improve on this.
Oh, and one of the technical challenges to using the passphrase itself to encrypt the whole data store is that every time you change the passphrase, you need to decrypt and re-encrypt the whole store. That's some nasty overhead. Just decrypting and re-encrypting the 1024-bit key I mentioned earlier would be much more plausible.
Like anything that's secured in software, the security is a joke when someone has physical access to the device. If it can be done in software, it can be bypassed in software given the chance to tweak or replace the binary.
That's some extraordinarily flawed reasoning.
I do not mandate planning for "the OSS community". I do not represent or speak for "the OSS community". I'm one person.
I never said it's necessarily better than it seems from those numbers. I only said it's not clearly as bad as some are trying to say those numbers mean. There's a big difference.
I'm not sticking my head in the sand, and I never suggested anyone else does.
If your incitement represents your understanding, then no, you do not "understand it right [sic]".
I don't have to adapt to anything. I'm not an Apache developer nor a Linux developer. I don't market nor sell those two projects. I do perform and contract to perform services which utilize those packages, but IIS gaining some market share does not diminish my ability to do so. Only if Linux and Apache go away (actually, only if Apache went away, as most of my stuff runs just as well on Solaris, BSD, and yes, even Windows) completely does it matter materially to my business. Both Apache and IIS growing at the expense of other web servers and in response to general growth of the market is not a sign of Apache going away.
While some in the OSS world do have an "us vs. them", "winner takes all", and/or "only my choice" mentality, that's far from the whole "OSS community", if such a broad label really carries much meaning at all. My favorite quick-snippet descriptions for OSS are "only the best craftsmen invite inspection" and "quit pissing in my pool".
OSS gives me a chance to see what I'm running and possibly fix it. In those cases I don't have the time or the skill to fix something, it at least gives me the chance to listen to the advice of skilled people who have access to the source. Many of them will fix things and share the fixes. I don't like putting crappy software on my systems that make diagnosing problem hard and fixing them harder or impossible. Messes do hide in Open Source software, but not for as long nor as easily as in closed source software. Locksmiths, doctors, auto engineers / mechanics, security experts, research scientists, mathematicians, and more publish what they've accomplished for review and use by others. Why shouldn't computer scientists, software designers, and programmers?
If I find closed-source software that's stable, does what I need it to do, and is flexible enough to keep doing what I need it to do, then I have no problem with paying a fair price for it and letting the developers keep it closed. It upsets me that so many companies expect hundreds or thousands of dollars from customers for buggy, unstable, insecure, inflexible messes that don't ever get fixed. If someone wants their software on my system, they won't let their software devalue my investment in my systems. The software should always add value, or otherwise why did I pay for it? That's what I mean by pissing in my pool. Some closed-source vendors don't do that, but too many do. OSS projects might suck, but if I'm not paying for the program then it's no loss to replace it with something else. If I'm paying for support, earlier access to new features, or something like that, those are things I'm choosing to buy. The source code that almost does something right even has inherent value over that of a closed binary that does the same thing. The developer or vendor of that Open Source code is being better to me and treating my systems with more respect than the closed-source vendor.
Open Source is sometimes considered a political movement. I think it's really more of a philosophical one. There's more than one way to make a buck in software development. There are probably fewer ways to really make significant progress in software development. Peer review and public comment seem to help quite a bit, and that's what's more important to most people than RMS's statements or any of the other manifestos.
A sysadmin's job is productive when you don't need to do the things that show you've not been productive. That's an awkward wayto say something that most admins already understand, so let me explain.
If you're researching new software, running performance numbers on new hardware before putting it in production, testing boxes, upgrading systems, patching systems, monitoring systems, rotating logs, etc, you're generally doing a pretty good job.
If you're fixing problems in production after they happen, coming in to the beeper because you don't have sufficient fail-over to last until morning, yelling at your hardware vendor that you need your expedited shipping even more expedited because your system utilization outstripped your expectations and your fudge factor, and basically "fighting fires" and reacting to problems rather than planning for them and preventing them, you could do better.
Measuring productivity of a sysadmin is a somewhat silly concept, really, because a sysadmin doesn't produce anything. A sysadmin is a manager (used to often be called "system manager" in fact), and "administrator" should be a sign of that. The fact that your resources are technological and not employees makes no difference. It is not your job for you to produce anything nor to be productive in any way.
Your job as a sysadmin is to make sure those you manage are productive. Hence, "production systems".
You could base your metrics on how many machine hours at what utilization you're getting out of your hardware and software. One way is the "useful utilization" metric. If you have ten production systems load balanced and one testing system that represents that configuration in tests, and you're running 90% utilization of the most limiting resource on those systems (CPU, memory, disk I/O, etc), then you're getting 90% productivity out of production servers and 81% productivity overall. Try to find another department in your company that runs at 90% average theoretical efficiency. If half of your systems are down on any given day of a week for four hours apiece for one reason or another, that's 4 * 5, or 20 hours out of your 168 * 10, or 1680 hours, times 0.9 (for the 90% utilization). That brings you down to about 87% on the production servers.
Another good metric I suppose is client requests served per dollar (yen, yuan, peso...) of hardware, software, and power investment. If you can figure out a dollar value of the average client request in some way, that can even point you towards ROI for the systems. A good sysadmin has a higher ROI from his systems than a poor one given the same hardware and software, after all.
I guess you could try to measure the admin by hours spent in proactive work vs. hours spent in reactive work. A good ticketing system could make this pretty trivial to track. However, if the standard ticket resolution is to power cycle a whole rack, this makes a very bad sysadmin look stellar. You'd also have to have a ticket queue and resolution tracking on research, upgrades, patches, server purchases, requisition writing, and other things which typically don't get tracked as closely as problem reports.
There's a popular idea that when anything on a public forum like Slashdot might be harmful to certain parties, this sort of sexual blather gets put in the thread so that porn and obscenity filters keep it out of many hands. Microsoft is the usual suspect, and the parent of the sex blather is questioning the effects on MS's EULA.
I'm not drawing any conclusions here, and I don't think anyone should at this point. It is an interesting theory, and this would be a prime example if it's true.
Assuming you're using waste heat from another process to bring the water to HTE temperatures, you actually do get more productive energy out of the hydrogen than the energy used to break the bonds with the oxygen. That waste heat is energy input, but it's energy that wasn't being used for anything before. Please read up on the process. It's not a cure-all, and it's not perpetual motion. It is very interesting.
Of course if someone is creating the heated environment only to perform steam electrolysis, that'd be a pretty inefficient way to do it. There are lots of processes we already use that create the necessary 300-700 degree C steam, or the potential for it. If by harnessing this wasted energy we can get a net gain on the electricity needed for the electrolysis, that's a win.
A for biofuels, I agree they are at least a good stopgap measure. They are better for not just chemical and ecological reasons in some ways, but they could be very helpful in the political and economic arenas within certain countries and internationally. Unfortunately, they also have some nasty limitations and side-effects of their own. Ethanol is much harder to transport than most forms of petrochemicals because of the types of materials needed to safely transport it. The best sources of ethanol from plants would appear to all be as geographically limited as oil, only in mostly different countries. Ethanol and biodiesel are currently largely being made from food crops, which can be a big drawback. There have been some promising results with biofuels from other sources, such as methanol from livestock farms and from algae-laden sewage treatment, but those haven't become reliable or mass-produced as of yet. Noone knows for sure how viable they may become. Burning biomass directly and using steam turbines, tapping landfill gas, burning latrine/septic tank methane, and more are possible, but each has issues. All in all, there's a lot of promise and a lot of caveats.
One of the biggest things we can do to help the situation is to go to more localized electrical generation, as we lose a great deal of efficiency through resistance and impedance in, for example, the North American power grid. It's odd that so few people make an issue out of that.
Pebble fission reactors might be the only well-proven technology we have that's able to be close to a single solution in the near term (rod-style reactors being relatively dangerous and ill-received) and uranium isn't really a renewable resource, either. Then there's the waste.
Essentially, we live in a time of great uncertainty about energy. There's likely not going to be one power source as dominant as petroleum has been, but I guess it's possible. After all, cars were once run on coal or wood steam engines, coal dust burned internally, kerosene burned internally, alcohol, kerosene steam engines, and even electricity before gas and diesel became standard enough to narrow the field. Homes were and often now are powered at least partly by natural gas or even wood. Alcohol, kerosene, and coal used to be popular for lights and heat as well. There's a possibility we'll see just a handful of power sources shine through again, but there's a great chance we'll be weighing how two products are powered along with other features when making buying decisions.
That's why they applied for the patent. They don't want the competition.
It is _almost_ possible. You're not putting any energy into the hydrogen through electrolysis. You're simply breaking the molecular bond it has to the oxygen. The oxygen is then released and not stored. Then, you're burning the hydrogen with atmospheric oxygen and producing water vapor, which gets released and not stored. There is waste in the heat and the friction, so you do lose some energy. You get most of it back because both processes are pretty efficient. HTE is even more power efficient than low-temperature electrolysis, especially if you already have a source of heat (nuclear, a blast furnace at a cement plant, geothermal, etc).
You would need additional energy inputs to the electrolysis stations besides just hydrogen, and that could be done with wind, solar, tidal, geothermal, and nuclear. Assuming you're using just regular grid power to produce the hydrogen from water, though, you could be burning hydrogen at one location to produce it at another.
Thankfully, instead of just burning hydrogen, we should hopefully soon have large fusion plants, which being atomic rather than chemical reaction have more than enough difference in power over electrolysis.
So yes, I oversimplified. My point is, it doesn't matter where you get the electricity for purposes of this discussion. There is a shortfall if you use only hydrogen to get the hydrogen, but it's no different than if you use only petroleum to drill, pump, refine, and transport petroleum. Large central hydrogen fusion plants that electrolyze steam along with smaller hydrogen production facilities using grid power or other power sources more than handle the demand if implemented satisfactorily.
We always live, at some scale, inside a sealed system. Solar seems renewable enough, but once our sun is gone, it's not coming back. Figuring out where one gets the additional energy into the system is _always_ an issue, even for biofuels.
Okay, I read a cache of the article. It doesn't answer any questions about what might not be stock Ubuntu 6.06, but simply assumes that uname/motd says it all.
Another option for a perfectly secure box that wasn't mentioned in TFA is that the friend could have run a Trojan that opened the initial hole.
Okay, I've not yet RTFA. Did it specifically say, "bog standard Ubuntu 6.06 with absolutely no additional software and only bare necessary configuration changes needed for system differentiation purposes"?
I ask because everyone seems to be looking very closely at the initial OS distro, and almost any server that's been put into useful production has been tweaked in some way from the official packages. Stuff gets compiled from source. Custom stuff gets coded. Packages get installed out of third-party repositories or straight from vendor sites. Daemon configurations get changed, firewall rules may be tweaked, and additional modules for existing server daemons get added.
Hell, they could have done something as stupid as allowing root logins through unencrypted telnet, then actually using that "feature".
Oh, well, off to RTFA to see if it contains any of the answers.
Burning hydrogen in an ICE gives you more power than it takes to separate it out of water. So you burn hydrogen to get the power to separate out more hydrogen from water. The problem is, if we're so concerned with crops because we're using the crops for other things, why aren't we worried about the crops because we're using the water for other things? You'd also be using hydrogen production that is also being used to create ammonia for fertilizers for the crops.
Yeah, you can electrolyze seawater, but when you take the seawater out of the sea and burn the hydrogen in cities and the rain falls near there rather than letting it evaporate at its normal rate from the normal places, you're changing weather patterns just as surely as with greenhouse gases.
You get better efficiency from hydrogen fuel cells than from burning hydrogen, but the cells are more expensive to produce and replace than ICEs. Fuel cell grid plants and vehicles might still be a better option than ICE or turbine ones. Pure electric vehicles are more efficient still, but then you have the batteries, the charging delays, etc.
Hydrogen ICE cars with small fuel cells for the electronics (so you're not burning it just to turn a generator with part of it) or completely hydrogen fuel cell powered cars may be a good balance between efficiency and range, as one can refuel hydrogen much faster than one can recharge batteries, and hydrogen (while dangerous in its own right) is probably safer in the long run than most battery technologies.
Oh, you'll get plenty of work out of a teenager on a sugar rush. It just won't necessarily be the work you asked him to do, and might not have any useful end result.