Electric vehicles charged on the power grid have lower global warming emissions than the average gasoline-based vehicle sold today
Better than average? That doesn't sound good. So where are these gasoline-based vehicles that are better than average, and outperform even fully-electric vehicles? I'm genuinely curious.
you may as well just shove those electrons into the battery
That depends on how efficient the charge/discharge cycle for the battery is, how expensive it is, how much weight it adds, etc.
And all that is irrelevant to the point... Conventional cars CAN indeed be run on clean fuels, just as EVs can run on clean or dirty sources of electricity.
now our money isn't going over to warlords and dictators in the middle east
When we started using oil, we were producing it all domestically as well. So now we're going to convert to coal, because we have enough of it... right now...
We could very well get stuck on coal, then a century from now, we're importing it from China because we don't have enough supply to meet electrical demand. That's more of a worst-case scenario, but it seems too many people are ignorant of the history of oil production.
I'm glad to see strong evidence of water on Mars, after so much conjecture and build-up. It will make it that much more humbling when they DON'T find any evidence of life on Mars.
You seem to be misunderstanding what VLAN1 vs tagging vs trunking are.
No, your ignorance of some of these issues is NOT a misunderstanding on my part...
Users don't need to be on a trunk port, they can just be on a VLAN that is used as the native vlan of some other trunk port, perhaps on some other switch (which should NEVER be VLAN 1 if you know what you're doing)... they can then embed a VLAN tag, and when it's sent to the next switch in the chain, over the trunk port, that user-inserted VLAN tag will be interpreted, and bingo, you've hopped VLANs.
The fact that you are apparently completely ignorant of some of these problems just reinforces my point that quite a bit of vigilance is needed to maintain any security at all on VLANs.
In any case, this discussion is incredibly tiresome. If you wish to remain ignorant of the security implications, be my guest.
Only if you did something ridiculously stupid, like set your access ports to allow trunking
Or if you leave your native VLAN as 1 (the default). Or if you don't explicitly turn on native VLAN tagging. Or if you don't remember to change the settings on EVERY port before you connect any of them. Or if you allow any access ports on the same VLAN that is the native vlan on trunks. Or if you run out of CAM space. Or...
VLANs can be configured to be secure, but in fact it's a hell of a lot of work and vigilance, as any little oversight can be a huge vulnerability.
You need to read-up on your VLAN security, because you don't seem to know what you're talking about. VLANs are NOT as secure as an air-gap. There are plenty of scenarios in which an attacker can forge VLAN tags or similar, and be able to hop from one VLAN to another without any restrictions (while this would NEVER be possible with a layer-3 router/firewall actually separating networks).
And saying that's all because of switch "misconfiguration" is just not true. There are some complex cases with VLANs, where things like VTP can be exploited, even if properly configured.
It's such that using VLANs to segregate secured and unsecured networks is simply not allowed by PCI-DSS and other security standards.
This is not as easy as you claim, and I highly doubt you ever did exactly this.
In fact I do this ALL THE TIME. One of my top bookmarks is a link to a Fedora Rawhide (SRPM) mirror site. I'm always doing rpmbuilds and upgrading RHEL libs and applications to something newer.
It was quite a bitch on RHEL5... Had to get a Fedora 14 rpm SRPM just to handle the XZ compression, newer checksums, etc., and RHEL5's base packages were so old, newer versions of anything could require rebuilding much of the base system.
On RHEL6, things are far, far easier. I've got plenty of upgraded Fedora components in my system, and I've never run into stability problems (while I'm always having issues when I try to actually use a stable Fedora release).
I'm not even running the stock kernel on any of my (Home) RHEL boxes: kernel-3.1.0-7.el6.x86_64
I can't speak to his EXACT scenario, only because I don't want and don't use GNOME to begin with.
it is impossible for two devices on different VLANs to communicate, short of a switch misconfiguration. Its probably second to air-gapping in terms of security
You're seriously over-stating the security of VLANs. While you should be safe if you follow the best practices, there are potential security issues to be aware of, and VLANs are certainly NOT more secure than layer-3 routing/firewalling.
VLANs are not for security! Any two things plugged into the same switch, whether virtual or real, can talk to each other if sufficiently motivated.
Umm, no. Not unless your switch is defective, or massively misconfigured. VLANs are very secure, when done properly. And the same security measures needed to protect VLANs are the same ones you need to protect switching in general (see CAM overflows, arp spoofing, and such).
If you leave your trunk/native VLAN at 1, you're in trouble. If you configure user-facing ports as auto-negotiate, or trunk without explicitly specifying allowed VLANs, you're in trouble.
No, there "may actually be/" 20 ways... The one you tried is not the best one, and not the first one you should try.
Why didn't you just forcibly upgrade glib & gtk2? I'm sure the package manager will complain, but keep going anyway, and find out if GNOME will work with the newer lib without problems... It just might.
Second to that, there's no reason you can't install multiple version of the same lib, in exactly the same location. This is not Windows... Linux has got lib versioning that works just fine. Install the latest glib / gtk/etc from RPMs, without replacing the existing libs, and then install GIMP and see how it all works.
This is all pretty easy to do, and a fairly common, simple, and standard thing for anyone who needs to upgrade their RHEL system beyond the provided packages. Most of the time you can just grab the Fedora SRPMs and compile them without trouble.
I agree this shouldn't happen. But it did. I lost access to the facilities of my local GNOME desktop and I don't really know why.
Of course that'll happen, if you maintain a completely seperate tree of libs, applications compiled with them won't be able to talk to GNOME, properly.
Of course neither Sony nor Microsoft is making big profits on their game consoles... Microsoft broke their way into the arena by dumping cheap hardware onto the market, so Sony is forced to cut their prices to stay alive and not become the next Sega.
But if the article's premise is true (that neither Nintendo nor Microsoft is really going to be a direct competitor to Sony in the next gen) then Sony's fate is looking-up, as without competitors, they won't need to cut prices to the bone to keep their market alive and well. They can tag an extra $50 onto the PS4's price tag, and people will just keep buying them, Sony's profits go up, and all is well. Supply and demand works like it always has.
There's no such thing as a product without competition that can't turn a profit...
It seems conflicting versions of GTK for the Desktop UI and the requirements of 2.8.x created a bit of an impossible situation.
I'm confused... What's the problem here? When you upgraded GTK to 2.8.x, did GNOME break? If so, when you installed gtk2-2.8.x along-side the old gtk, what failed to work?
It is GNOME's fault for selecting GTK instead of forking it or something else.
Hell no! GTK is a library, and developers should NOT be scared away from using libraries of other projects. The only way you can avoid issues such as the one you're having with libraries is to statically compile everything, which isn't a good idea, nor a good option.
Besides that, Linux is robust, and there's no reason tow different libraries can't be installed side-by-side. Whether you have a hard time doing that with a package manager, or you don't know that you can do it, it's still not the fault of the library, or of projects depending on that lib.
Since there's no urgency here, it will be fine if it takes another generation or so to fully transition.
There are substantial costs involved in having to manage with two incompatible measurement systems. Never mind needing to convert between each one, how about every mechanic in the US needing to have two sets of tools for ever size, metric and SAE, doubling the cost. That's a huge, huge cost across the economy.
Since the rest of the industrialized world uses metric, the sooner the US completely switches over, the sooner we'll start seeing big savings from not having to be "multi-lingual".
And let's not mention the costs of spacecraft crashing into the faces of other planets.
Except for the "no class action" clause in the AT&T's contract.
Well, we're screwed, then.
Those "no class action" clauses are likely unenforceable unless they give you a reasonable way to opt-out (and you're just too lazy to do so, like most customers).
Now let's just hope that the no-contract month-to-month plans don't disappear.
They won't... There's too many people on them, who would be willing to jump to the next provider at a moment's notice. If one of the big 4 dropped their contract plans, some tiny company would go around putting up cell towers, and trump them all.
Hell, WiFi tech is almost good enough that you could use APs to provide VoIP across whole metropolitan areas, for far, far less than the price of cell tower infrastructure. If competition doesn't get them, technology eventually will...
I pay like $78 per month for what on ATT or VZW now costs about $120 or so - I get a new phone and sign a new contract every two years
If that's for one phone, that doesn't sound like a good deal, at all.
Boost Mobile (Sprint) has unlimited voice/sms/data on Android at $55/mo, and has "shrinkage" which drops that by $5 every 6 months (if you pay on-time). After staying for just 18 months, you're only paying $40/mo, indefinitely, with no contract and no fees. And that's the TOTAL price... No surcharges, no taxes, no fees, etc.
As for phones, Boost has some decent ones for $80. Get a new one every 2 years, and you're adding just $3/mo on to your bill, for a grand total of $44/mo., or a bit more than half what you're paying for your wonderful grandfathered-in plan.
I wouldn't be caught dead signing a cell phone contract. If Boost/Sprint ever pissed me off, I'd switch to some other service immediately... No fees, no nothing. That's probably why they just DON'T DO THAT to their customers, ever.
Re:The name Ethernet is 40 years old...
on
Ethernet Turns 40
·
· Score: 3, Insightful
In some ways, the great success of Ethernet is that it became the name we gave to whatever technology won out.
No, ethernet remained relevant because it was able to improve, while maintaining backwards compatibility along the way, so your investment was never wasted.
10Base-T cards still had BNC connectors on them, letting you transition smoothly from one to the other.
100Base-Tx was backwards compatible with 10Mbps hubs & NICs.
Gigabit offered backward compatibility with 100Base-Tx.
Switching between fiber and copper is just a matter of swapping the GBIC/SFP transceivers in a switch, with the underlying device having no clue that the media is different.
Newer standards retained backward compatibility with older, less robust cabling... From CAT-3 to CAT-5, to CAT-5e/6, to CAT-6a.
Even though ethernet of today doesn't look like it did, originally. The upgrade path was always simple, smooth, and inexpensive, so it is very much an unbroken chain back to the beginning, and hooking up a modern PC to one of the first ethernet devices is a simple matter of physical-layer conversion.
I wonder what kind of atmosphere conditions you could use to accommodate better cooling? Would a vacuum work better, or would high pressure work better for removing heat from the systems? Are nitrogen, CO2, Oxygen, or other gases better at transferring heat?
A vacuum would mean absolute NO cooling. The denser the gas, the more heat it could haul away, so something like argon would probably be best.
However, you could do much better by submerging the whole thing in Fluorinert or other (cheaper) non-conductive and non-corrosive fluid. The downside to that, being both that traditional hard drives will cease to function, and the weight of a building full of fluid will be astronomical, and would also require extremely tighter tolerances and far more horizontal support.
The only way I could see that working, would be a huge subterranean datacenter... Basically a huge hole in the ground, or perhaps the world's deepest in-ground pool.
I've been in plenty of datacenters, and I don't see where you're getting any benefit with radical redesigns. They aren't exactly designed for human comfort in the first place...
Lighting? Sure, but motion sensors mean it's only on when someone is in that area. And you'll still need lights, because humans will surely still be going in there to fix the malfunctioning robots, and hiring old coal miners seems excessive.
Temperature? No, the servers dictate the temperature the datacenter is kept at, while human comfort is completely secondary. The 15C degree air coming out of the floor vents below my KVM doesn't make for a comfortable experience, but nobody cares. Humans in the datacenter are the foreigners, who must adapt themselves, not the other way around. If Google could run their datacenters at 75C degrees, they WOULD do that now, and the humans would be sent in with ice packs strapped to their bodies.
Height? If a couple more feet of rack height were useful and cheap, I would be happy enough to keep a bit of scaffolding in my datacenter cages. As for the ridiculous heights predicted, it's not going to happen. Racks can't scale-up that easily (they'd need huge thick vertical supports to handle the weight)... and at some point, it's pretty easy to just install another "floor" for those pesky humans to walk on, install air ducts in, and also avoid the need for super-robust racks... and I can't even imagine that crazy air currents that would be happening with 100' of vertical servers pumping out crazy amounts of heat, not to mention problems like CLOUDS forming and potentially raining, INSIDE the building.
In general, the comparison needs to be made to warehouses... If Amazon/Walmart/etc. had fully-automated warehouses, I'd say automated datacenters would be just around the corner. But they don't... Humans are still very much in the loop, driving around on electrified forklifts or pallet jacks, and doing what the computer tells them to, and when. And if any business could benefit from vertical expansion, quicker response times, and less humans, it's warehousing, but it just doesn't work there, yet. That will be a lot closer to the model for future datacenters, not this pie-in-the-sky nonsense.
Slashdot Mirror
And there's no mechanism to get free electricity for an electric vehicle, so what's your point?
Better than average? That doesn't sound good. So where are these gasoline-based vehicles that are better than average, and outperform even fully-electric vehicles? I'm genuinely curious.
That depends on how efficient the charge/discharge cycle for the battery is, how expensive it is, how much weight it adds, etc.
And all that is irrelevant to the point... Conventional cars CAN indeed be run on clean fuels, just as EVs can run on clean or dirty sources of electricity.
As they have been for at least the past 40 years, and still with zero success... Algae likes to die off instead of scaling-up.
When we started using oil, we were producing it all domestically as well. So now we're going to convert to coal, because we have enough of it... right now...
We could very well get stuck on coal, then a century from now, we're importing it from China because we don't have enough supply to meet electrical demand. That's more of a worst-case scenario, but it seems too many people are ignorant of the history of oil production.
Yes, I believe you can... How about hooking-up a hydrogen source to the air intake? Very clean exhaust, and hydrogen is renewable.
And you are wrong...
I'm glad to see strong evidence of water on Mars, after so much conjecture and build-up. It will make it that much more humbling when they DON'T find any evidence of life on Mars.
No, your ignorance of some of these issues is NOT a misunderstanding on my part...
Users don't need to be on a trunk port, they can just be on a VLAN that is used as the native vlan of some other trunk port, perhaps on some other switch (which should NEVER be VLAN 1 if you know what you're doing)... they can then embed a VLAN tag, and when it's sent to the next switch in the chain, over the trunk port, that user-inserted VLAN tag will be interpreted, and bingo, you've hopped VLANs.
The fact that you are apparently completely ignorant of some of these problems just reinforces my point that quite a bit of vigilance is needed to maintain any security at all on VLANs.
In any case, this discussion is incredibly tiresome. If you wish to remain ignorant of the security implications, be my guest.
Or if you leave your native VLAN as 1 (the default). Or if you don't explicitly turn on native VLAN tagging. Or if you don't remember to change the settings on EVERY port before you connect any of them. Or if you allow any access ports on the same VLAN that is the native vlan on trunks. Or if you run out of CAM space. Or...
VLANs can be configured to be secure, but in fact it's a hell of a lot of work and vigilance, as any little oversight can be a huge vulnerability.
You need to read-up on your VLAN security, because you don't seem to know what you're talking about. VLANs are NOT as secure as an air-gap. There are plenty of scenarios in which an attacker can forge VLAN tags or similar, and be able to hop from one VLAN to another without any restrictions (while this would NEVER be possible with a layer-3 router/firewall actually separating networks).
And saying that's all because of switch "misconfiguration" is just not true. There are some complex cases with VLANs, where things like VTP can be exploited, even if properly configured.
It's such that using VLANs to segregate secured and unsecured networks is simply not allowed by PCI-DSS and other security standards.
In fact I do this ALL THE TIME. One of my top bookmarks is a link to a Fedora Rawhide (SRPM) mirror site. I'm always doing rpmbuilds and upgrading RHEL libs and applications to something newer.
It was quite a bitch on RHEL5... Had to get a Fedora 14 rpm SRPM just to handle the XZ compression, newer checksums, etc., and RHEL5's base packages were so old, newer versions of anything could require rebuilding much of the base system.
On RHEL6, things are far, far easier. I've got plenty of upgraded Fedora components in my system, and I've never run into stability problems (while I'm always having issues when I try to actually use a stable Fedora release).
I'm not even running the stock kernel on any of my (Home) RHEL boxes: kernel-3.1.0-7.el6.x86_64
I can't speak to his EXACT scenario, only because I don't want and don't use GNOME to begin with.
You're seriously over-stating the security of VLANs. While you should be safe if you follow the best practices, there are potential security issues to be aware of, and VLANs are certainly NOT more secure than layer-3 routing/firewalling.
Umm, no. Not unless your switch is defective, or massively misconfigured. VLANs are very secure, when done properly. And the same security measures needed to protect VLANs are the same ones you need to protect switching in general (see CAM overflows, arp spoofing, and such).
http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a008013159f.shtml
If you leave your trunk/native VLAN at 1, you're in trouble. If you configure user-facing ports as auto-negotiate, or trunk without explicitly specifying allowed VLANs, you're in trouble.
No, there "may actually be/" 20 ways... The one you tried is not the best one, and not the first one you should try.
Why didn't you just forcibly upgrade glib & gtk2? I'm sure the package manager will complain, but keep going anyway, and find out if GNOME will work with the newer lib without problems... It just might.
Second to that, there's no reason you can't install multiple version of the same lib, in exactly the same location. This is not Windows... Linux has got lib versioning that works just fine. Install the latest glib / gtk /etc from RPMs, without replacing the existing libs, and then install GIMP and see how it all works.
This is all pretty easy to do, and a fairly common, simple, and standard thing for anyone who needs to upgrade their RHEL system beyond the provided packages. Most of the time you can just grab the Fedora SRPMs and compile them without trouble.
Of course that'll happen, if you maintain a completely seperate tree of libs, applications compiled with them won't be able to talk to GNOME, properly.
Of course neither Sony nor Microsoft is making big profits on their game consoles... Microsoft broke their way into the arena by dumping cheap hardware onto the market, so Sony is forced to cut their prices to stay alive and not become the next Sega.
But if the article's premise is true (that neither Nintendo nor Microsoft is really going to be a direct competitor to Sony in the next gen) then Sony's fate is looking-up, as without competitors, they won't need to cut prices to the bone to keep their market alive and well. They can tag an extra $50 onto the PS4's price tag, and people will just keep buying them, Sony's profits go up, and all is well. Supply and demand works like it always has.
There's no such thing as a product without competition that can't turn a profit...
I'm confused... What's the problem here? When you upgraded GTK to 2.8.x, did GNOME break? If so, when you installed gtk2-2.8.x along-side the old gtk, what failed to work?
Hell no! GTK is a library, and developers should NOT be scared away from using libraries of other projects. The only way you can avoid issues such as the one you're having with libraries is to statically compile everything, which isn't a good idea, nor a good option.
Besides that, Linux is robust, and there's no reason tow different libraries can't be installed side-by-side. Whether you have a hard time doing that with a package manager, or you don't know that you can do it, it's still not the fault of the library, or of projects depending on that lib.
There are substantial costs involved in having to manage with two incompatible measurement systems. Never mind needing to convert between each one, how about every mechanic in the US needing to have two sets of tools for ever size, metric and SAE, doubling the cost. That's a huge, huge cost across the economy.
Since the rest of the industrialized world uses metric, the sooner the US completely switches over, the sooner we'll start seeing big savings from not having to be "multi-lingual".
And let's not mention the costs of spacecraft crashing into the faces of other planets.
Those "no class action" clauses are likely unenforceable unless they give you a reasonable way to opt-out (and you're just too lazy to do so, like most customers).
They won't... There's too many people on them, who would be willing to jump to the next provider at a moment's notice. If one of the big 4 dropped their contract plans, some tiny company would go around putting up cell towers, and trump them all.
Hell, WiFi tech is almost good enough that you could use APs to provide VoIP across whole metropolitan areas, for far, far less than the price of cell tower infrastructure. If competition doesn't get them, technology eventually will...
If that's for one phone, that doesn't sound like a good deal, at all.
Boost Mobile (Sprint) has unlimited voice/sms/data on Android at $55/mo, and has "shrinkage" which drops that by $5 every 6 months (if you pay on-time). After staying for just 18 months, you're only paying $40/mo, indefinitely, with no contract and no fees. And that's the TOTAL price... No surcharges, no taxes, no fees, etc.
As for phones, Boost has some decent ones for $80. Get a new one every 2 years, and you're adding just $3/mo on to your bill, for a grand total of $44/mo., or a bit more than half what you're paying for your wonderful grandfathered-in plan.
I wouldn't be caught dead signing a cell phone contract. If Boost/Sprint ever pissed me off, I'd switch to some other service immediately... No fees, no nothing. That's probably why they just DON'T DO THAT to their customers, ever.
KiBbles & bits? Absolutely!
No, ethernet remained relevant because it was able to improve, while maintaining backwards compatibility along the way, so your investment was never wasted.
10Base-T cards still had BNC connectors on them, letting you transition smoothly from one to the other.
100Base-Tx was backwards compatible with 10Mbps hubs & NICs.
Gigabit offered backward compatibility with 100Base-Tx.
Switching between fiber and copper is just a matter of swapping the GBIC/SFP transceivers in a switch, with the underlying device having no clue that the media is different.
Newer standards retained backward compatibility with older, less robust cabling... From CAT-3 to CAT-5, to CAT-5e/6, to CAT-6a.
Even though ethernet of today doesn't look like it did, originally. The upgrade path was always simple, smooth, and inexpensive, so it is very much an unbroken chain back to the beginning, and hooking up a modern PC to one of the first ethernet devices is a simple matter of physical-layer conversion.
CONFIRMED:
https://en.wikipedia.org/wiki/Vehicle_Assembly_Building
We're 3/4ths of the way there!!!
A vacuum would mean absolute NO cooling. The denser the gas, the more heat it could haul away, so something like argon would probably be best.
However, you could do much better by submerging the whole thing in Fluorinert or other (cheaper) non-conductive and non-corrosive fluid. The downside to that, being both that traditional hard drives will cease to function, and the weight of a building full of fluid will be astronomical, and would also require extremely tighter tolerances and far more horizontal support.
The only way I could see that working, would be a huge subterranean datacenter... Basically a huge hole in the ground, or perhaps the world's deepest in-ground pool.
I've been in plenty of datacenters, and I don't see where you're getting any benefit with radical redesigns. They aren't exactly designed for human comfort in the first place...
Lighting? Sure, but motion sensors mean it's only on when someone is in that area. And you'll still need lights, because humans will surely still be going in there to fix the malfunctioning robots, and hiring old coal miners seems excessive.
Temperature? No, the servers dictate the temperature the datacenter is kept at, while human comfort is completely secondary. The 15C degree air coming out of the floor vents below my KVM doesn't make for a comfortable experience, but nobody cares. Humans in the datacenter are the foreigners, who must adapt themselves, not the other way around. If Google could run their datacenters at 75C degrees, they WOULD do that now, and the humans would be sent in with ice packs strapped to their bodies.
Height? If a couple more feet of rack height were useful and cheap, I would be happy enough to keep a bit of scaffolding in my datacenter cages. As for the ridiculous heights predicted, it's not going to happen. Racks can't scale-up that easily (they'd need huge thick vertical supports to handle the weight)... and at some point, it's pretty easy to just install another "floor" for those pesky humans to walk on, install air ducts in, and also avoid the need for super-robust racks... and I can't even imagine that crazy air currents that would be happening with 100' of vertical servers pumping out crazy amounts of heat, not to mention problems like CLOUDS forming and potentially raining, INSIDE the building.
In general, the comparison needs to be made to warehouses... If Amazon/Walmart/etc. had fully-automated warehouses, I'd say automated datacenters would be just around the corner. But they don't... Humans are still very much in the loop, driving around on electrified forklifts or pallet jacks, and doing what the computer tells them to, and when. And if any business could benefit from vertical expansion, quicker response times, and less humans, it's warehousing, but it just doesn't work there, yet. That will be a lot closer to the model for future datacenters, not this pie-in-the-sky nonsense.