Re:Why did they buy ATI?
on
Is AMD Dead Yet?
·
· Score: 2, Insightful
When you are designing architectures for 7 or so years out, you need a powerful crystal ball, but no such thing exists. AMD just guessed wrong about the nature of future applications. Intel guessed wrong with the Itanium also. Maybe the common thread is you have to fit existing apps instead of the other way around. But, betting against app change has risk also.
That is actually part of the success of AMD64. Intel tried to move off of x86. However, x86 compatibility proved too powerful, and AMD had bet on that for the AMD64 arch. Thus, they beat Intel. Intel then had to scramble to implement AMD64 (as EMT64E, now renamed Intel64) and catch up. They're still doing so to a degree.
And honestly, I think AMD's approach to multi-cores (Quad+) is really where they'll benefit in the long run. Intel, while they were able to get a short-run boost, is still going to have to figure that problem out to compete in the long run. So, AMD is still ahead in many respects, even if they are not fully benefiting from it today - they will tomorrow.
Business is not just a matter of the quarterlies, or even the year-to-year. You have to think Short term to stay ahead today, but you also have to have a good long term plan. AMD64 and the multi-core approach AMD has invested in are certainly good for the long term health of the company. With AMD64 they get to control this round of the instruction set; with their multi-core approach they get to save money later as that approach will be what's required in the long term.
Honestly, think about it. AMD's multi-core approach is the right design to multi-core. Intel's approach, however, is like patching a program - it gets the job done, but the real work is still head. AMD will be better off for what they did, and they will see the benefits. If they followed Intel's approach, then not only would they have had to do what they did, but they would have also spent a lot of extra money doing Intel's band aide approach too. So they have already saved themselves money. Not to mention that they essentially did their multi-core approach in about the same time as Intel did their approach, namely because they thought about it when they did their implementation of AMD64. (Intel didn't get that advantage since EMT64E/Intel64 was just a band aide around IA-32 to get x86 64-bit compatible CPUs quick to market.)
The ATI purchase isn't too different either - after all, think of how many systems have built-in graphics cards. They could easily take that market over so a minimal GPGPU + basic interface chipset (to the Output port - VGA/DVI/etc) is all that is needed for those systems. They would also get the benefit of being able to aid a normal graphics card, so high-end graphics would be able to pull more performance by having its specialty plus the GPGPU extensions. Need combo.;-)
Needless to say, I like the fact that AMD's management did the right thing for the long term.
The spin won't make any additional energy (if that was the case, making a perpetual motion machine would be dead simple), at best it will just convert some of the energy to heat due to friction thus making the system less than 100% efficient. The entire system is powered by the weight falling. There is no other source of energy. The path the weight takes from top to bottom, or the motion of other parts of the system caused by the weight moving down does not in itself magick up more energy. You do realized you just showed one method it could work as heat can be converted to energy, which can then be used to a power light.
True you do have to obey the laws of thermodynamics and such. Gravity pushes the object down (downward force) the spin converts it to a partial horizontal force. The trick would be in the threads - getting them at the right angle so that gravity continues to push down, while siphoning off a little bit of the energy from gravity. That siphoned energy is then converted to electricity and used to power the device. It's still obeying the laws of thermodynamics - no energy is created nor destroyed, just converted.
As I said - the trick is in the angle of the threads. They turn the object round as it goes down by nature of being threaded, they also decide the rate at which it falls. They also have to be smooth enough and tilted enough that the energy they siphon does not subtract enough from gravity to stop the drop. But it has to be threaded in order to keep the drop within the chamber and make it easy to deploy.
It's like putting a block on a slanted slope. For degrees 0 to X, the mass of the object and friction keeps it in place. Then at X+1, the object starts to ever so slightly slide as gravity + its mass being to overcome friction. Increasing X increases the rate at which the object slides. Add another method of friction (e.g. siphoning of some of the energy from the drop) and the X at which it the process starts increases to a higher value. It'll still happen.
I'm sure you can extrapolate the workings of the device from there as it's just putting that basic physics experiment onto a screw, with the threads at that special degree of X+1 so that gravity+mass yield enough force to overcome friction.
So yes, it is very well possible. Go back to physics 101.
A bridge is a bridge, and they should all be engineered pretty much in the same way. You can't say the same thing about software. You can't say the same thing about software.
Well, actually you can. It's just a bit different since in mechanical engineering, you will have one that will specialize in bridges, and another in autos, etc; but management won't try to take a bridge engineer and make him design autos. Where as in Software, it is often the case that the software engineer with specialty X will be asked to do work that requires specialty in Y. Yes, to a degree there is an overlap - just like with the mechanical engineers - but often there is a vast difference.
So just like mechanical engineering a bridge is a bridge, but a bridge is not a car. Similarly an application is an application, but an application is not a device driver.
There is a point you miss there I think. It is the top-to-bottom design philosophy vs the bottom-to-top. The first one gives objectives first then designs every part so that it fulfills the general objective. The latter focuses on designing simples elements and assemble them as more complex elements with defined capacities and known weaknesses.
This article states that the second approach is inherently better than the top-to-bottom approach. This is clearly an engineering problem. I am not sure I agree with the conclusions and acknowledge that most of the Challenger disaster was due to unwelcomed pressure, but I don't think you can dismiss the whole issue as not concerning engineering. I wouldn't necessarily agree that the Top-Down approach is 100% bad. Both have their strengths and weaknesses for what they can see and cannot see. Bottom-up tends to get too involved in the details, while Top-Down tends to outright ignore the details.
However, please, please, please,..(can I say it enough?).., please do not mix the two - have one part top-down and another bottom-up. Be consistent in design methodology across the entire project, and find the appropriate balance of both methods.
The drop is a screw so it's magnitudes more than 58".
And exactly how does having a screw generate more energy?
The path the weight takes to the ground is irrelevant.
An object weighing X lifted to a height of Y meters generates has a certain amount of potential energy, regardless of the path taken to the ground. So the drop powers the spin of the object which in turn powers the lights. It's not simply the drop itself, and in this case the path does matter since the spin will generate additional power as well as decide the length of time it takes to make the drop. In this case, they designed the spin to generate enough power for the 10W LEDs and for it to take 4 hours to reach bottom.
Personally, I think this is more about the spin than the drop itself. So it does make a big difference.
Go to a Big Box Computer Retailer, use cash to buy an expensive item you know the manager won't "just let you return" in the interest of customer satisfaction, take it home, open it, start to install it, click "no, I don't agree," then try to return it. Use cash so it's clear you don't have recourse through your credit-card company.
the crypto can sometimes be the bottleneck instead of the wire speed.
Between two devices on my gigabit home LAN, the CPU barely even registers while
SCP'ing a large file (and that with every CPU-expensive protocol option
turned on, including compression). What sort of connection do these guys have,
that the CPU overhead of en/decryption throttles the transfer???
Coming next week: SSH compromised via a thread injection attack, thanks to
a "feature" that only benefits those of us running our own undersea fiber. A worked on a program that is similar to what the summary describes. For various legacy reasons (legacy code-base) we only supported Triple-DES encryption. But the bottlenecks break down as follows:
Network Bandwidth
CPU/encryption
Disk Access
Network bandwidth is easily over-come to a degree - in the manner the summary describes, it will easily fill the pipe if you can get past the other two issues.
CPU/encryption - this is really more the encryption and how much it affects you will depend on what algorithm you use. For example, our tests with Triple-DES enabled would limit a 100 Mbps pipe to around 30 to 40 Mbps; with encryption disabled we would get around 94 to 96 Mbps. I didn't have a change to try an AES algorithm, but it should give better performance than Triple-DES. Now you don't always have the encryptor on the actual computer - you might have it in-line with your network connection, which will yield higher performance via dedicated encryption hardware, but it will still eat your bandwidth. (I'm aware of in-line encryptors taking 1.5 Mbps links down to around 700 Kbps.)
Disk Access - this is the hardest to overcome as you can really only improve by changing your disk drives to a disk array of some sort (e.g. some sort of striped RAID), or putting in a super-fast connectivity to the disks (e.g. Fibre-Channel), or both. It's still a pretty hard physical limit to break.
Of course, you may still have some issues with Operating System implementations too. Linux tends to do better than Windows, for example - probably due to using better algorithms across the system.
I did manager to test the program I was working on on a gigabit network. We peaked at 500 Mbps for up to 2 seconds, then dropped to under 200 Mbps. The limitation? The hard drives couldn't keep up. I did not have any further opportunity to do more testing for that program.
All together, that's what an EE is. If it's not on fire, we can program it;D Oh come on....even if it is on fire, we can program it. The fire just makes it more fun.;-)
On a more serious note gliding or "flying" under water as means of improving fuel efficiency and maneuvrability are not new. Research has been going on this since the 60-es. None of it has produced anything particularly spectacular.
Neat design, though there is a simpler way to do it. Put some solars on the glider, charge it on the surface, after that use the energy to compress the air used to expell the ballast tank. Sink. Reach target depth (gliding). Spew out ballast the same way a submarine does. Float up. Gliding. Sit on the surface while charging for another dive.
Trivial to do. No need for complex thermal stuff and you can probably survey half of the Pacific at a leasurely pace on one run until your batteries run out of charge cycles. This type of kit needs to float to the surface to transmit data back to base anyway, so why not do something productive in the meantime. That would only work for limited dives; extended dives would be heavily dependent on your batteries and their ability to charge fast enough for your time on the water. Also, forget about any black-ops with such a design - for that you need to be under water as much as possible.
TFA's design is pretty cool and would work even for extended dives. Since it doesn't require surfacing black-ops are also possible. It could probably reach deeper depths, and longer periods at deeper depths would be a given.
That said, adding some solars might be useful to charge while its surfaced, but they shouldn't be required for the sub to work, which your proposed design would require.
...So the future of convergence between PC and TV will probably be not in all-in-one systems but in devices that link the PC in your study with the TV in your living room, and since there's no household name yet for PC-to-TV linkage, the field is wide open for some lucky company to make a product that becomes synonymous with the concept, the way "TiVo" is easier to say than "Digital Video Recorder". Maybe that will be a boost for systems like Vista. If that happens at about the same time that a Vista successor is released that makes the interface easier to switch to from XP, I'll bet that will be the tipping point that gets people switching voluntarily. (Of course many people will switch by then just because they need a new computer and they couldn't find one with anything but Vista on it.)
Actually this has been tried before - Gateway released the Destination TV/PC back around 1998. (Sorry, Wikipedia doesn't link it.) It was a powerhouse of a system (at the time) and had a 35" TV for its monitor. Gateway no longer carries it though - and I believe sales weren't that great. That said, it was far ahead of its time. So a similar prospect may do better now. (You can find it listed as "Destination PC" under the support page - at least I think that's it; I know I have issues of the Gateway2000 magazine that include it at home.)
Any how...I don't really see something like that taking off unless a projector is used instead of a monitor or TV. I plan on doing just that in my own house at some point in the future. But the system(s) that drive it will be primarily dedicated to performing a movie theater experience for movies instead of just normal TV, though a tuner card will likely be there for the air/cable channels too. It's more about the BIG screen and movie theater experience than anything else - and I'd rather drop $2k on a projector than on an LCD/plasma TV - especially since I get a lot bigger picture out of it in the end (and it stays needly tucked away [out of sight, out-of-mind] when not in use).
[snip]...why they dispose of user email if said user is unable to access their mailbox for a remarkably short amount of time -- a month, IIRC. I used to set reminders so that this wouldn't happen to my backup hotmail.com accounts but now I just let it happen -- useless hotmail.com mailboxes being toasted by a useless company seems appropriately bizarre. Probably has something more to do with the fact that some people (I know a few) would use Hotmail accounts for jokes on fellow co-workers. One such prank went as follows: A worker put up a wreath for the Christmas season. Another co-worker took it down within a few days and hid it. (Wreath was okay by company policy.) Several co-workers started e-mailing from various hotmail accounts acting as "kidnappers" of the wreath. It kept up for some time, after which the wreath was returned to its owner. (No, I was not involved in this in any way...I only heard the funny stories - the e-mails sent were quite funny.) All-in-all, this was a joke, and everyone understood it. (YMMV). But they took up a number of hotmail accounts in the process - after which they just left them.
Actually, Dome A is one of the least windy places on Earth, typically just 2-3 metres per second. Dome A is the highest point in the centre of the Antarctic plateau, and this is where the katabatic winds start from. The winds accelerate as they head towards the coast, and that is where they can reach 100's of kph.
So, unfortunately, wind power was not feasible.
So then it seems like there are two choices: (i) put the wind power elsewhere and run a cable from there (inefficient and could cause lots of problems), or (ii) build the turbines to work with vertical winds instead of horizontal windows or some angle thereof as determined by the site. It's not that wind power is not feasible, just that it needs to be harnessed differently.
I work somewhere that uses the commercial EPHD product (I think this is it). I believe the systems actually got less secure after installing EPHD.
To start, the Single Sign-on allows entry of username/password at boot, and then by-passes the Windows login. Even if you time-out at the Windows login, it will usually just let you in.
If you fail to provide the correct password after 3 to 5 times, it prompts to call the help desk for a special code. However, if you simply turn off the computer and turn it back on, you can try again. Repeat until you get it right.
You cannot have multiple people/users recognized for the login. Only one user can login to EPHD. So, people (even managers) started creating dummy users for systems and told others how to generate the password for the users so that more than one person could login. Keep in mind password sharing is forbidden by policy.
We also had a 50% success rate with installation because it kept corrupting the master FAT table. Kept the techs busy for a few weeks as they tried to sort it all out. They had to rebuild my system 2 or 3 times before it took.
There's good ways to manage it - BitArmor seems to have a good method; though I've not actually used it myself yet.
Not sure how TrueCrypt compares to either, but it can't be any worse - likely its better.
With no ability to NAT or firewall in IPV6 , anyone on the external Internet can find out exactly what you have, theb stage targeted attacks on every single host on a private network.
End-user netblocks are 2^64 addresses in size. If an attacker could ping a billion hosts per second, it would still take them 585 years to scan a single block.
So, again, NAT-as-security is even dumber on IPv6 than it is on IPv4.
Wrong. It only takes one PING to be successful. Remember - security through obscurity (which is all that your suggestion would be) is not security at all. Use NAT and control your network better. It's not a dumb solution - it's smart security practice and helps limit the foot-print of a network on a larger network - also smart as it minimizes the points someone has to compromise and maximizes what they have to figure out/know to do so.
But here's the thing. The GGP says "we don't need IPv6" because NAT does everything *he* wants. You can still, I believe (I'm no IPv6 expert, and haven't played with it much, but if I get some free time it's something I want to play more with), do NAT with IPv6 if you really *want* to. My problem is that the attitude that "we don't need IPv6 because NAT solves the problem" is just wrong. It solves *some* problems, but not other problems.
I think I'm agreeing with you - but here's my basic opinion:
IPv6 should only be about expanding the address range. It is not a solution to give out IPv6 addresses to all devices and get rid of NAT; nor is it sufficient to say that NAT solves all problems and we don't need IPv6.
Reality is that IPv4 addresses will run out. So will IPv6 if we just let everything on the planet have an IP address - but that's not necessary. Reality is that we should convert our IPv4 addresses to IPv6 and pretty much leave the NATs and firewalls the same. We'll have to do that eventually any way.
Reality is that DHCP is a very effective method for handing out IP addresses, and the new "dynamic" IP assignment built-into IPv6 is (IMO) junk. A network administrator should be able to determine the IP address of all systems on the network. While dynamic addressing like what is built-into IPv6 is nice in theory, in practice it is not good; and any competent network admin or network security administrator will know why.
We really need to change how we are thinking of IPv6. For the most part, both sides are wrong; and until we can get that through, we won't really get the right solution.
Re:It's a sham - the Internet is mostly dark
on
One Step Closer to IPv6
·
· Score: 2, Interesting
Getting back to end-to-end networks is what needs to happen (no more NAT), and IPv6 is the way.
That's assuming I want all my devices to be publicly visible. What if I don't? While NAT is a little PITA to set up, it works beautifully for the job. I don't want people to be able to easily figure out the all the systems on my network, and even if I converted my network to IPv6, I want a solution like NAT.
NAT just makes it easy for the network to have a single point-of-contact going in/out of the network.
And Firewall issues would still be the same - as far as having to poke-holes, etc. And not-having firewalls would make for a rather in-secure network and not solve any of the problems that we have today any way.
So the issue really is an IP allocation issue, and NATing would be good regardless of using IPv4 or IPv6. It would be nice for everyone to be able to have a static IP at their network gateway, but not beyond that.
As Hotmail likely had at least GMails user's base before Microsoft took them over - and that was before Gmail existed! - I'd give it to Hotmails lifespan compared to GMail's.
Personally - I have both Yahoo! (primary) and GMail. I prefer Yahoo! because I use folders, and I don't see GMail's labels as being equivalent - for my users, labels are mostly useless. If GMail did support folders, then I'd probably use it more - but that's a personal preference. Overall, GMail is just a usable - if not more so since POP3/IMAP access (while not guaranteed) is free too, while everyone else has gone to charging for it.
I'll be sticking with my Yahoo! account as a primary for now - but if Microsoft does succeed in buying Yahoo!, then I'll be planning my move away from Yahoo!.
I will say this - I've had a Yahoo! e-mail account since roughly 1999. If Microsoft does manage to buy Yahoo!, I will take my services elsewhere - and yes, I pay for my account. The pain of moving away from one centralized account to something else (likely getting my own domain and paying for a hosting service, which would be a lot better than what I have now) would be worth not supporting Microsoft.
I work for a company that does CMM, CMMI, SixSigma, LEAN, etc. However, I have not seen it actually improve anything.
I certainly do believe that certain CMM/CMMI stuff is very valuable and would greatly contribute to making software better; however, the documentation overhead it brings is a nightmare to manage and keep up to date. Honestly, I think we really need to do better with coming to a compromise to the overbearing documentation that CMM/CMMI systems bring and the chaos that typically at the other end.
Software does need to be engineered, and it does need to be done in such a way that helps think about the future...but you also have to balance with actually making the system practical to use - which is what I was trying to get at. The way people use LiveLink/SharePoint makes it entirely useless - sure, it solves the legal requirements, but it's not worth the cost of the installation disk it came on because it just tosses tons of info in without any real consideration for how to get it back out since the people managing it don't know beans about managing such data.
Well...I better end any rants there...needless to say, there's a balance that needs to be achieved.
I'd highly recommend staying away from things like SharePoint and LiveLink. I've used both, and in both cases they get high disorganized and information becomes extremely hard to find. I'm on a project now that uses LiveLink and when asking a question, a lot of people will just go "it's in LiveLink" or "go look in LiveLink" - only LiveLink is so chaotic that it'll take you far longer to find it (if you even can find it) than for someone to just give you the real answer to your question. Same goes with SharePoint.
Additionally, management looks at SharePoint and LiveLink as a form of RCS, but people will typically not using the versioning side - i.e. go to a document, select add version, upload new version - when uploading new versions of a document - they'll just upload a new document, perhaps with a different name that you may or may not recognize as being a new version of some document X. This only adds to the problem of disorganization I mentioned above.
That said...it's a really touch job to figure out and do. If you need an RCS like system, then I'd suggest looking at using Subversion via webDAV mapped as drives to people systems or something similar - but you'll still have a problem with people not doing versioning right.
I've also been in the proverbial "someone was hit by a bus" situation (the person left for a vacation and died; not sure what happened, but it wasn't a bus) and had to pick up the pieces. Fortunately it was just software and the code was fully available (after a time), but even so it took us a full cycle to fully understand what was going on and create our own documentation about it (e.g. adding more comments to the code, writing stuff down for consideration for the next version, etc.) so it wasted a lot of money, but we couldn't avoid it.
Unfortunately for you, you're at a non-profit which means funds to do anything like this are even tighter, and any hit in finances will likely kill your project first unless management is really 200% sold that it will save them money in the long run, in which case they'll prioritize whose functions you have to document so that they can eliminate those positions - which will only lead to less help from any of the employees. (Even more unfortunate for you it's highly likely you'll hit this kind of scenario in the near future given the economy and 2007's 6.3% inflation rate.)
So take a breather, think things through and I'd highly recommend starting with upper management with the documentation process, and then working your way down - start with at the top, add the key employees, and end with the employees that have high turnover. (They'll likely have good info already and will feel the most vulnerable, so leave them till last.)
Great, more space junk. Thanks pal. Nah...they'll burn up on re-entry...though we'll just have to track their hearts as stone won't so easily burn up and might actually get through. Thankfully we have NORAD for that;-)
I heard that when you switch to FIOS they remove your POTS lines.
Also, from what I'm guessing, it you don't like your ISP providing the FIOS connection, you cannot get another ISP that can use that FIOS connection.
IOW: you are just locking yourself into another monopoly. One of my friends use to work for Cox Cable, and they'd get calls after Verizon would turn on FIOS at a site due to Verizon cutting all of the copper cables - including Cox's coax - when they installed it. Not sure if they did it also when they ran FIOS past a house or not, but they were not being ethical in their practices on its roll-out at least at one stage.
What about the artists that put their own stuff out on P2P networks? You going to kill people's ISP accounts for downloading what artists rightfully put out their? (And I'm talking about artists that fully own their stuff and don't have to worry about whether a label has rights to it.) I think both artists and people very much have a right to trade that stuff over P2P. (Yes, I plan on doing this myself. Working on setting up my own sound studio at the moment.)
Slashdot Mirror
And honestly, I think AMD's approach to multi-cores (Quad+) is really where they'll benefit in the long run. Intel, while they were able to get a short-run boost, is still going to have to figure that problem out to compete in the long run. So, AMD is still ahead in many respects, even if they are not fully benefiting from it today - they will tomorrow.
Business is not just a matter of the quarterlies, or even the year-to-year. You have to think Short term to stay ahead today, but you also have to have a good long term plan. AMD64 and the multi-core approach AMD has invested in are certainly good for the long term health of the company. With AMD64 they get to control this round of the instruction set; with their multi-core approach they get to save money later as that approach will be what's required in the long term.
Honestly, think about it. AMD's multi-core approach is the right design to multi-core. Intel's approach, however, is like patching a program - it gets the job done, but the real work is still head. AMD will be better off for what they did, and they will see the benefits. If they followed Intel's approach, then not only would they have had to do what they did, but they would have also spent a lot of extra money doing Intel's band aide approach too. So they have already saved themselves money. Not to mention that they essentially did their multi-core approach in about the same time as Intel did their approach, namely because they thought about it when they did their implementation of AMD64. (Intel didn't get that advantage since EMT64E/Intel64 was just a band aide around IA-32 to get x86 64-bit compatible CPUs quick to market.)
The ATI purchase isn't too different either - after all, think of how many systems have built-in graphics cards. They could easily take that market over so a minimal GPGPU + basic interface chipset (to the Output port - VGA/DVI/etc) is all that is needed for those systems. They would also get the benefit of being able to aid a normal graphics card, so high-end graphics would be able to pull more performance by having its specialty plus the GPGPU extensions. Need combo.
Needless to say, I like the fact that AMD's management did the right thing for the long term.
True you do have to obey the laws of thermodynamics and such. Gravity pushes the object down (downward force) the spin converts it to a partial horizontal force. The trick would be in the threads - getting them at the right angle so that gravity continues to push down, while siphoning off a little bit of the energy from gravity. That siphoned energy is then converted to electricity and used to power the device. It's still obeying the laws of thermodynamics - no energy is created nor destroyed, just converted.
As I said - the trick is in the angle of the threads. They turn the object round as it goes down by nature of being threaded, they also decide the rate at which it falls. They also have to be smooth enough and tilted enough that the energy they siphon does not subtract enough from gravity to stop the drop. But it has to be threaded in order to keep the drop within the chamber and make it easy to deploy.
It's like putting a block on a slanted slope. For degrees 0 to X, the mass of the object and friction keeps it in place. Then at X+1, the object starts to ever so slightly slide as gravity + its mass being to overcome friction. Increasing X increases the rate at which the object slides. Add another method of friction (e.g. siphoning of some of the energy from the drop) and the X at which it the process starts increases to a higher value. It'll still happen.
I'm sure you can extrapolate the workings of the device from there as it's just putting that basic physics experiment onto a screw, with the threads at that special degree of X+1 so that gravity+mass yield enough force to overcome friction.
So yes, it is very well possible. Go back to physics 101.
So just like mechanical engineering a bridge is a bridge, but a bridge is not a car. Similarly an application is an application, but an application is not a device driver.
This article states that the second approach is inherently better than the top-to-bottom approach. This is clearly an engineering problem. I am not sure I agree with the conclusions and acknowledge that most of the Challenger disaster was due to unwelcomed pressure, but I don't think you can dismiss the whole issue as not concerning engineering. I wouldn't necessarily agree that the Top-Down approach is 100% bad. Both have their strengths and weaknesses for what they can see and cannot see. Bottom-up tends to get too involved in the details, while Top-Down tends to outright ignore the details.
However, please, please, please,..(can I say it enough?).., please do not mix the two - have one part top-down and another bottom-up. Be consistent in design methodology across the entire project, and find the appropriate balance of both methods.
The path the weight takes to the ground is irrelevant.
An object weighing X lifted to a height of Y meters generates has a certain amount of potential energy, regardless of the path taken to the ground.
So the drop powers the spin of the object which in turn powers the lights. It's not simply the drop itself, and in this case the path does matter since the spin will generate additional power as well as decide the length of time it takes to make the drop. In this case, they designed the spin to generate enough power for the 10W LEDs and for it to take 4 hours to reach bottom.
Personally, I think this is more about the spin than the drop itself. So it does make a big difference.
Th3y just w4nt t0 p4wn 4ll t3h n3tw0x! B1llyG mu$t b3 0n3 3l1t3 k1dd13...
;-)
No seriously...they're now writing the virus?!!! I guess they've given up on actually producing relatively secure software then...
Just like the old saying - if you can't beat them, join them.
Yet another reason to go to Linux, Mac, or something else.
Between two devices on my gigabit home LAN, the CPU barely even registers while SCP'ing a large file (and that with every CPU-expensive protocol option turned on, including compression). What sort of connection do these guys have, that the CPU overhead of en/decryption throttles the transfer???
Coming next week: SSH compromised via a thread injection attack, thanks to a "feature" that only benefits those of us running our own undersea fiber.
A worked on a program that is similar to what the summary describes. For various legacy reasons (legacy code-base) we only supported Triple-DES encryption. But the bottlenecks break down as follows:
- Network Bandwidth
- CPU/encryption
- Disk Access
Network bandwidth is easily over-come to a degree - in the manner the summary describes, it will easily fill the pipe if you can get past the other two issues.CPU/encryption - this is really more the encryption and how much it affects you will depend on what algorithm you use. For example, our tests with Triple-DES enabled would limit a 100 Mbps pipe to around 30 to 40 Mbps; with encryption disabled we would get around 94 to 96 Mbps. I didn't have a change to try an AES algorithm, but it should give better performance than Triple-DES. Now you don't always have the encryptor on the actual computer - you might have it in-line with your network connection, which will yield higher performance via dedicated encryption hardware, but it will still eat your bandwidth. (I'm aware of in-line encryptors taking 1.5 Mbps links down to around 700 Kbps.)
Disk Access - this is the hardest to overcome as you can really only improve by changing your disk drives to a disk array of some sort (e.g. some sort of striped RAID), or putting in a super-fast connectivity to the disks (e.g. Fibre-Channel), or both. It's still a pretty hard physical limit to break.
Of course, you may still have some issues with Operating System implementations too. Linux tends to do better than Windows, for example - probably due to using better algorithms across the system.
I did manager to test the program I was working on on a gigabit network. We peaked at 500 Mbps for up to 2 seconds, then dropped to under 200 Mbps. The limitation? The hard drives couldn't keep up. I did not have any further opportunity to do more testing for that program.
On a more serious note gliding or "flying" under water as means of improving fuel efficiency and maneuvrability are not new. Research has been going on this since the 60-es. None of it has produced anything particularly spectacular.
Neat design, though there is a simpler way to do it. Put some solars on the glider, charge it on the surface, after that use the energy to compress the air used to expell the ballast tank. Sink. Reach target depth (gliding). Spew out ballast the same way a submarine does. Float up. Gliding. Sit on the surface while charging for another dive.
Trivial to do. No need for complex thermal stuff and you can probably survey half of the Pacific at a leasurely pace on one run until your batteries run out of charge cycles. This type of kit needs to float to the surface to transmit data back to base anyway, so why not do something productive in the meantime. That would only work for limited dives; extended dives would be heavily dependent on your batteries and their ability to charge fast enough for your time on the water. Also, forget about any black-ops with such a design - for that you need to be under water as much as possible.
TFA's design is pretty cool and would work even for extended dives. Since it doesn't require surfacing black-ops are also possible. It could probably reach deeper depths, and longer periods at deeper depths would be a given.
That said, adding some solars might be useful to charge while its surfaced, but they shouldn't be required for the sub to work, which your proposed design would require.
Any how...I don't really see something like that taking off unless a projector is used instead of a monitor or TV. I plan on doing just that in my own house at some point in the future. But the system(s) that drive it will be primarily dedicated to performing a movie theater experience for movies instead of just normal TV, though a tuner card will likely be there for the air/cable channels too. It's more about the BIG screen and movie theater experience than anything else - and I'd rather drop $2k on a projector than on an LCD/plasma TV - especially since I get a lot bigger picture out of it in the end (and it stays needly tucked away [out of sight, out-of-mind] when not in use).
Actually, Dome A is one of the least windy places on Earth, typically just 2-3 metres per second. Dome A is the highest point in the centre of the Antarctic plateau, and this is where the katabatic winds start from. The winds accelerate as they head towards the coast, and that is where they can reach 100's of kph.
So, unfortunately, wind power was not feasible.
So then it seems like there are two choices: (i) put the wind power elsewhere and run a cable from there (inefficient and could cause lots of problems), or (ii) build the turbines to work with vertical winds instead of horizontal windows or some angle thereof as determined by the site. It's not that wind power is not feasible, just that it needs to be harnessed differently.- To start, the Single Sign-on allows entry of username/password at boot, and then by-passes the Windows login. Even if you time-out at the Windows login, it will usually just let you in.
- If you fail to provide the correct password after 3 to 5 times, it prompts to call the help desk for a special code. However, if you simply turn off the computer and turn it back on, you can try again. Repeat until you get it right.
- You cannot have multiple people/users recognized for the login. Only one user can login to EPHD. So, people (even managers) started creating dummy users for systems and told others how to generate the password for the users so that more than one person could login. Keep in mind password sharing is forbidden by policy.
We also had a 50% success rate with installation because it kept corrupting the master FAT table. Kept the techs busy for a few weeks as they tried to sort it all out. They had to rebuild my system 2 or 3 times before it took.There's good ways to manage it - BitArmor seems to have a good method; though I've not actually used it myself yet.
Not sure how TrueCrypt compares to either, but it can't be any worse - likely its better.
End-user netblocks are 2^64 addresses in size. If an attacker could ping a billion hosts per second, it would still take them 585 years to scan a single block.
So, again, NAT-as-security is even dumber on IPv6 than it is on IPv4.
Wrong. It only takes one PING to be successful. Remember - security through obscurity (which is all that your suggestion would be) is not security at all. Use NAT and control your network better. It's not a dumb solution - it's smart security practice and helps limit the foot-print of a network on a larger network - also smart as it minimizes the points someone has to compromise and maximizes what they have to figure out/know to do so.IPv6 should only be about expanding the address range. It is not a solution to give out IPv6 addresses to all devices and get rid of NAT; nor is it sufficient to say that NAT solves all problems and we don't need IPv6.
Reality is that IPv4 addresses will run out. So will IPv6 if we just let everything on the planet have an IP address - but that's not necessary. Reality is that we should convert our IPv4 addresses to IPv6 and pretty much leave the NATs and firewalls the same. We'll have to do that eventually any way.
Reality is that DHCP is a very effective method for handing out IP addresses, and the new "dynamic" IP assignment built-into IPv6 is (IMO) junk. A network administrator should be able to determine the IP address of all systems on the network. While dynamic addressing like what is built-into IPv6 is nice in theory, in practice it is not good; and any competent network admin or network security administrator will know why.
We really need to change how we are thinking of IPv6. For the most part, both sides are wrong; and until we can get that through, we won't really get the right solution.
NAT just makes it easy for the network to have a single point-of-contact going in/out of the network.
And Firewall issues would still be the same - as far as having to poke-holes, etc. And not-having firewalls would make for a rather in-secure network and not solve any of the problems that we have today any way.
So the issue really is an IP allocation issue, and NATing would be good regardless of using IPv4 or IPv6. It would be nice for everyone to be able to have a static IP at their network gateway, but not beyond that.
As Hotmail likely had at least GMails user's base before Microsoft took them over - and that was before Gmail existed! - I'd give it to Hotmails lifespan compared to GMail's.
Personally - I have both Yahoo! (primary) and GMail. I prefer Yahoo! because I use folders, and I don't see GMail's labels as being equivalent - for my users, labels are mostly useless. If GMail did support folders, then I'd probably use it more - but that's a personal preference. Overall, GMail is just a usable - if not more so since POP3/IMAP access (while not guaranteed) is free too, while everyone else has gone to charging for it.
I'll be sticking with my Yahoo! account as a primary for now - but if Microsoft does succeed in buying Yahoo!, then I'll be planning my move away from Yahoo!.
I will say this - I've had a Yahoo! e-mail account since roughly 1999. If Microsoft does manage to buy Yahoo!, I will take my services elsewhere - and yes, I pay for my account. The pain of moving away from one centralized account to something else (likely getting my own domain and paying for a hosting service, which would be a lot better than what I have now) would be worth not supporting Microsoft.
I work for a company that does CMM, CMMI, SixSigma, LEAN, etc. However, I have not seen it actually improve anything.
I certainly do believe that certain CMM/CMMI stuff is very valuable and would greatly contribute to making software better; however, the documentation overhead it brings is a nightmare to manage and keep up to date. Honestly, I think we really need to do better with coming to a compromise to the overbearing documentation that CMM/CMMI systems bring and the chaos that typically at the other end.
Software does need to be engineered, and it does need to be done in such a way that helps think about the future...but you also have to balance with actually making the system practical to use - which is what I was trying to get at. The way people use LiveLink/SharePoint makes it entirely useless - sure, it solves the legal requirements, but it's not worth the cost of the installation disk it came on because it just tosses tons of info in without any real consideration for how to get it back out since the people managing it don't know beans about managing such data.
Well...I better end any rants there...needless to say, there's a balance that needs to be achieved.
I'd highly recommend staying away from things like SharePoint and LiveLink. I've used both, and in both cases they get high disorganized and information becomes extremely hard to find. I'm on a project now that uses LiveLink and when asking a question, a lot of people will just go "it's in LiveLink" or "go look in LiveLink" - only LiveLink is so chaotic that it'll take you far longer to find it (if you even can find it) than for someone to just give you the real answer to your question. Same goes with SharePoint.
Additionally, management looks at SharePoint and LiveLink as a form of RCS, but people will typically not using the versioning side - i.e. go to a document, select add version, upload new version - when uploading new versions of a document - they'll just upload a new document, perhaps with a different name that you may or may not recognize as being a new version of some document X. This only adds to the problem of disorganization I mentioned above.
That said...it's a really touch job to figure out and do. If you need an RCS like system, then I'd suggest looking at using Subversion via webDAV mapped as drives to people systems or something similar - but you'll still have a problem with people not doing versioning right.
I've also been in the proverbial "someone was hit by a bus" situation (the person left for a vacation and died; not sure what happened, but it wasn't a bus) and had to pick up the pieces. Fortunately it was just software and the code was fully available (after a time), but even so it took us a full cycle to fully understand what was going on and create our own documentation about it (e.g. adding more comments to the code, writing stuff down for consideration for the next version, etc.) so it wasted a lot of money, but we couldn't avoid it.
Unfortunately for you, you're at a non-profit which means funds to do anything like this are even tighter, and any hit in finances will likely kill your project first unless management is really 200% sold that it will save them money in the long run, in which case they'll prioritize whose functions you have to document so that they can eliminate those positions - which will only lead to less help from any of the employees. (Even more unfortunate for you it's highly likely you'll hit this kind of scenario in the near future given the economy and 2007's 6.3% inflation rate.)
So take a breather, think things through and I'd highly recommend starting with upper management with the documentation process, and then working your way down - start with at the top, add the key employees, and end with the employees that have high turnover. (They'll likely have good info already and will feel the most vulnerable, so leave them till last.)
Good luck - you'll need it.
Also, from what I'm guessing, it you don't like your ISP providing the FIOS connection, you cannot get another ISP that can use that FIOS connection.
IOW: you are just locking yourself into another monopoly. One of my friends use to work for Cox Cable, and they'd get calls after Verizon would turn on FIOS at a site due to Verizon cutting all of the copper cables - including Cox's coax - when they installed it. Not sure if they did it also when they ran FIOS past a house or not, but they were not being ethical in their practices on its roll-out at least at one stage.
What about the artists that put their own stuff out on P2P networks? You going to kill people's ISP accounts for downloading what artists rightfully put out their? (And I'm talking about artists that fully own their stuff and don't have to worry about whether a label has rights to it.) I think both artists and people very much have a right to trade that stuff over P2P. (Yes, I plan on doing this myself. Working on setting up my own sound studio at the moment.)