Forgive me if I have this wrong, but if we start wiring houses for low voltage DC, won't this mean huge fat copper cables to deal with the current implications of a washing machine or oven pulling tens, even hundreds of amps because of Ohms law?
For data processing workloads, a frequent problem with GPU acceleration is that the working dataset size is too large to fit into the available GPU memory and the whole thing slows to a crawl on data ingest (physical disk seeks, random much of the time) or disk writes for persisting the results.
For folks serious about getting good ROI on their GPU hardware in real world scenarios, I strongly recommend you take a look at the fusion IO PCIe flash cards, which now support writing to and reading from them directly from CUDA via DMA, with little to no CPU handling required. (See: http://developer.download.nvidia.com/GTC/PDF/GTC2012/PresentationPDF/S0619-GTC2012-Flash-Memory-Throttle.pdf).
I can't talk about what we do with it, but lets just say the following hardware combination has lead to interesting results; i) 16x PCIe slot chassis: http://www.onestopsystems.com/expansion_platforms_3U.php ii) 8x Nvidia Kepler K20x's iii) 8x Fusion IO 2.4TB IoDrive 2 Duo's
We have been able sustain over 4 million data operations a second, each one processing ~16 K of data in a recoverable, transactionally consistent manner, totaling up to around 50 Gigabytes of data processed per second. All in a 5U deployment drawing less than 4 kilowatts.
Not to bash Oracle, but the ultimate scalability of their multi-host database partitioning solution (RAC) is indeed limited by the amount of communication the distributed lock manager needs to make to ensure transactional isolation as the number of partitions/hosts increase. (Caveat to Oracle fans - 80% of requirements are beneath this threshold - so I understand Oracle's strategy.) (An alternative solution is the "shared nothing" partitioning approach (example - db2's DPF) but this has its own drawbacks too.)
I don't pretend for a second to know all the answers - indeed I suspect that some of them are yet to be invented/utilized effectively by industry.
My major point is that having distributed application side data caches will soon become very tempting in terms of the latency involved with accessing data. There are admittedly great challenges involved with doing this safely, in a way which is scalable as you point out and providing a productive application interface.
It will be very interesting over the next few years as we collectively work out the best approach to these requirements. Anybody can be wrong - me of all people - but my bet is that most of these problems will be solved. How they will be is the coolest part:) .
The best methodology on how to efficiently and robustly manipulate large data sets in the application tier is still up for debate. In memory databases are but one potential solution to this requirement - there are many others. The javaspaces/gigaspace grid style solution is another.
Every current approach to this issue at present has is pros and cons - that's the price for being on the bleeding edge I guess.
What cannot be ignored is that we are on the edge of a potential paradigm shift - one powered by the fact that available system memory is about to surpass the size of the average state of a complex system. How this will effect our application design is still very much up for grabs, but be assured it will.
In my mind as a database engineer for a wall street bank, the biggest change in the near term that we forsee is data locality.
Given the amount of computing power on hand today, it may surprise many how difficult it is to engineer a system capable of executing more than a few thousand transactions per second per thread.
Why? Latency. Consider your average SOA application which reaches out to 4-5 remote services or dataserver calls to execute its task. Each network/rpc/soap/whatever call has a latency cost of anything between one and at worst several hundred milliseconds. Lets say for example that the total latency for all the calls necessary is 10 milliseconds. 1000/10=100 transactions per thread per second. Oh dear.
The amount of memory an "average" server ships with today is in the 32-64GB range. Next year it will be in the 64-128GB range. The average size of an OLTP database is 60-80GB.
So, the amount of memory available to the application tier will very soon be greater than the size of the database, warehouses excluded. Moore's law is quickly going to give the application tier far more memory than it needs to solve the average business state, exceptions noted.
The final fact in the puzzle is that for transaction processing, read operations outnumber write operations by roughly 20 to 1. (This will of course vary on the system, but that *is* the average.)
This situation is strongly in favor in migrating read only data caches back into the application tier, and only paying for the network hop when writes are done in the interests of safety. (There is a lot of research into how writes can be done safely asynchronously at the moment, but its not ready yet IMHO.)
Challenges exist in terms of efficient data access and manipulation when caches are large, performant garbage collection and upset recovery - but they are all solvable with care.
Its my opinion that in the near future large data caches in the application tier will become the norm. What has to be worked out is the most effective way of accessing, manipulating and administering that data tier and dealing with all the inevitable caveats of asynchronous data flow.
Some (not complete) examples of implementing this:
Relational Caches (there are many more): http://www.oracle.com/technology/products/coherence/coherencedatagrid/coherence_for_java.html http://www.alachisoft.com/ncache/index.html
I aggree with this - I find the architecture of Oracle very creaky - there is no clean abstraction of some of its components. This results in a "bolt on" feel.
Sybase ASE and Ms SQL have very clean system schemas - you get a feeling for how the system works just by looking at the relational diagram for them. (Ms have broken theirs a bit since they inherited ASE, but I digress.)
Oracle on the other hand is so non intuative that most of the useful system tables are really views to hide the real mess underneath...;)
That said, nobody can deny that once its up and running, the Oracle does work very well and is quite amazingly tolerant of poorly written SQL and Cursors. (Cursors IMHO break the whole relational idea, but I digress.) Its certainly its biggest strength after MVCC.
I really must find the time to look at Postgres or MySQL with the appropiate ACID moduled compiled in. Would people care to comment on how these look?
Amusingly enough, I too am now off to the bathroom..;)
Other vendors out there don't get just how important this feature is.
In particular, Sybase ASE (which Microsoft SQL server is based on) *still* does not have this feature. Sybase's slant on it goes "If you design your system correctly, the fact that selects block updates does not matter in an OLTP system. Implementing MVC carries a significant overhead.". I have tried in vain for many years to convince them that:
a) The hard truth of the world is that very few systems are well designed. A good RDBMS should try and service even the worst of these.
b) Blocking lock strategies degrade very badly under load - the minute the system starts to slow down, the chance of blocking increases, which slows the system down further - see a repeating pattern here??
c) DSS style systems die without multi version control. Ever tried updating your system when somebody is running a 6 hour report against it?
I personaly don't like the Oracle product itself (its architecture from a DBA's perspective is a dogs breakfast compared to Sybase ASE, IBM's UDB/DB2, Informix or Ms SQL server), but this feature alone makes it perform far better that any of these in most real world situations.
Why other competitiors don't get this is beyond me...
Ever have one of those weeks? This has just not been the best couple of days for me or for Valve.
Yes, the source code that has been posted is the HL-2 source code.
Here is what we know:
1) Starting around 9/11 of this year, someone other than me was accessing my email account. This has been determined by looking at traffic on our email server versus my travel schedule.
2) Shortly afterwards my machine started acting weird (right-clicking on executables would crash explorer). I was unable to find a virus or trojan on my machine, I reformatted my hard drive, and reinstalled.
3) For the next week, there appears to have been suspicious activity on my webmail account.
4) Around 9/19 someone made a copy of the HL-2 source tree.
5) At some point, keystroke recorders got installed on several machines at Valve. Our speculation is that these were done via a buffer overflow in Outlook's preview pane. This recorder is apparently a customized version of RemoteAnywhere created to infect Valve (at least it hasn't been seen anywhere else, and isn't detected by normal virus scanning tools).
6) Periodically for the last year we've been the subject of a variety of denial of service attacks targetted at our webservers and at Steam. We don't know if these are related or independent.
Well, this sucks.
What I'd appreciate is the assistance of the community in tracking this down. I have a special email address for people to send information to, helpvalve@valvesoftware.com. If you have information about the denial of service attacks or the infiltration of our network, please send the details. There are some pretty obvious places to start with the posts and records in IRC, so if you can point us in the right direction, that would be great.
We at Valve have always thought of ourselves as being part of a community, and I can't imagine a better group of people to help us take care of these problems than this community.
Gabe
__________________ Gabe Newell
Great use for 802.11 & || bluetooth on ipods
on
New iMacs (and iPods)
·
· Score: 4, Interesting
I am beginning to wonder when apple will be brave enough to release what has to be the "killer" 802.11 application for mp3 players - personal streaming.
Just imagine how cool it would be to share your music and playlists with any other ipod user within range. Tired of your own collection? Try listening to Bob's ipod 4 seats behind you.
The register has also thought about this - http://www.theregister.co.uk/content/39/28467.html
What do people think? I would love this, but there are - erm - interesting legal aspects..;)
This is without a doubt of the more impressive HCI developments I have seen in the last decade, and steady progress is being made.
I note that progress is also beging made in the reverse process (generating an image by monitoring neurons firing in the visual cortex). Check out this paper:-
Which details images generated directly from a cats brain.
One point to keep in mind is that sadly this technology can only help people whom had sight at birth, but lost it after early childhood. If the patient has been blind from birth, the parts of their brain that would be normally used for vision have not developed and have been "reassigned" to other sensory tasks. (Which is why blind people tend on average to have more actue senses of hearing, smell, touch and taste - there are more neurons available to process them!)
If this device was deployed on such a person, it is doubful that they could make much sense of what they could "see".
Just a sidenote - in Europe (well - London) Nestle already sell similar cans of self heating coffee. Works quite well - shame about the taste of whats in the can though. I can't remember the reactants - but the oxidser is diluted hyrogen preoxide.
All the 30 first stage motors are identical Kuznetsov Design Bureau NK-33's generating 154 metric ton's of thrust each.
There is a lot of debate about why the Soviets chose this approach, but for me its a combination of three reasons:-
a) Previous Soviet Rockets were also based on the "many small engines" approach - they worked fine. (Even if it was not the most efficient approach)
b) A key reason the the N-1 ended up with 30 NK-33 engines instead of something more manageable was political infighting. The Soviet chief engine disigner Glushko had an intense argument over fuel choice with the N1 designer Korolov and ended up taking experience to the Soviet military with the UK-500 and 700 boosters. That left Korolov with no engine designer and in the end the N-1 had it's engines designed from existing templates.
c) At the time there were real doubts over the feasibility of combistion stability in engines with large injector surfaces. (Ie - large engines). It took Rocketdyne many, many tests to get the F-1 to work. The Soviets felt that developing these large engines was simply too risky (and expensive), despite the obvious efficiency gains.
Hi All,
Quick question - does anybody have a source of Audreys in the UK? I can't seem to find anybody still selling them. (The US web sites are not that keen on shipping them internationally....)
I can't believe I am just about to platform bash, but:-
Please don't rule out Sybase for large systems. I work for a large investment bank, and we use both Sybase and Oracle heavily. (As you would imagine a bank might..:) )
Whilst Oracle does have the edge for indexing extremely large DSS systems (bitmap indexing..) Sybase is more than capable of holding its own - even for tables >20Gb in size with rowcounts in the tens of millions. People tend to forget just how much cheaper than Oracle Sybase is - IMHO it offers much more bang for buck...
If only its technical support in the UK did not suck rocks most of the time...:-)
Assuming the reports are accurate, the only reason these guys/gals are successful in these schemes is because there are people out there naueve enough to fall for their social attacks.
Yes, they did work the system, but I don't see anything here to be worried over - people will simply have to learn that you don't give your credit card details out on a whim...
The only thing that does concern me is that people like this provide the powers at be the perfect excuse to attack anonimity...:(
Scene:-Computer Lab
Student: Excuse me, but what is the command for deleting a directory and all its subtrees?
Lab Technician: rm -rf
Student: Are you sure?
Lab Technician: Yes
On a serious note, as voice enabled computer technology becomes more common, what standards are there to enable us to seperate computer commands from normal conversation?
Do we have to be like ST and prefix everyhting with "computer", or are there more intelligent ways?
I (like most of the people here) still value paper manuals for a number of reasons.
1. Eye Strain. Display technology is making leaps and bounds, but I STILL feel a bit odd after looking at a computer screen of more than a few hours. Manuals can place a bit of variety in this. 2. The "Bog" factor. Manuals can go *many* places a computer/laptop couldn't. Be it bed/toilet/train. 3. The multiplicity factor. If my desk is big enough, I can have 4 manuals open at the same time and cross reference between them. This can be very useful at times - try doing this on a 14" monitor.;-) 4. The failure factor. If all else fails, and my system goes down in flames, the paper manual will still be there.
That said, there are a *lot* of advantages of having "online" manuals. I predict that "online" manuals will eventually phase out the paper ones, but only when the following conditions are met, negating my previous gripes.
1. When display technology gets good enough for me not to notice the difference between laser printed paper ( >600 dpi) and a VDU (be it LCD, LEP - whatever) 2. When there exists computer systems that are light, convienent and rugged enough to survive as well as paper manuals in various places. I suppose an advanced enough "e-book" style device might do here. 3. When the aforementioned "e-book" systems are cheap enough for me to have multiple units. 4. The "e-book" systems *have* to be extremely reliable - no running out of batteries at the wrong time, etc. etc.
Its only when these, and more, conditions are met will we see the phasing out of the demand for paper manuals. That said, I think we will have the change forced upon us before that time, simply because its a way for the software companies to save a few pence. *sigh* Time to get new glasses....;-)
It is seems to me that the Chinese government is a little too hopeful about what they want to achieve. From what I understand the Chinese government has two goals in the construction of this "firewall".
a) To prevent access to foreign "propoganda" sites that might encourage China's citizen's to become more resistant to the Communist Party's wishes. (It would appear that they consider the New York Times to be one.;-) )
b) To prevent the orginaisation of grassroot political groups via the internet.
Anyone here will know that a) is simply impossible. Sites can change URL's in a matter of minutes, multiple mirrors etc etc. (We need only look at how poor some of the existing "censorship" products are in the West to realise that what China's government want to do is extremely difficult.)
They do however, have a better chance at preventing b), with possible human rights implications. The article states that the only ISP in China is run by the government. Since they control the remote access equipment, it would be fairly trivial not to stop someone from sending "undersirable" material, but to find out whom did. (eg. Search google one too many times about democracy and you might have a surprise visit from the local army squad.) Presumably the use of encryption would also render you immediately suspect. It will be interesting to see how this one develops...
More information on WIG Aircraft
on
Flying Trains
·
· Score: 2
As has been said in previous comments, the Wing In Ground effect is something that has actually been known about for some time. (The first evidence came from the Pilots of early Dornier flying boats.) I have found a site that deals with this effect, and the aircraft that have exploited it at:- http://www.io.tudelft.nl/~twai o/edwin/html/index.htm
We all know how well Linux performs on mid range to low end hardware. (I run 2.2 on mid range Dell Poweredges and a am very pleased with its performance.)
However, various recent benchmarks and editorials have pointed out Linux'es problems when it comes to perfroming well on high end servers. If memory serves me correct, this was mainly due to the SMP support in the 2.2 kernel and the TCP/IP stack, along with other problems with device drivers. (eg. Ethernet Card). It was my understanding that the kernel SMP support was being re-written for 2.4 to address some of the shortcomings and to help performance in general on high end machines.
So my question is, how much actually has been done in the 2.3/2.4 tree to address these performance issues? (Feel free to correct me if anything I have said here is wrong - but then you would probably do that anyway;-) )
It is a sad fact, but a lot of these local stores will quite happily ripoff anyone if they think they can get away with it. I know, I used to work for one. Common tricks were (in the olden days):-
1. Removing the print on 486's/Pentiums and reprinting them as the next model up. (They sadly got away with this 99.99% of the time - the systems were soak tested before delivery) 2. 66 Mhz Ram for 100 Mhz (again, got away with it all the time - how to YOU know your memory is 100Mhz??? V.Hard to tell. I left before the days for 100Mhz RAM, but I know someone that works there still) 3. For our own systems we had a hacked BIOS image that reported standard SIMMS as EDO, when they were just FPM. 4. Some HDD Manufacturers used to sell drives that had failed some QC test on the cheap. (I don't believe they do anymore). We used to have low level format utilities that would format a 2BG drive full of bad sectors into a 1.6GB drive. We would then sell them. 5. Got Mutsumi 6x cd-drives that reported themselves as 8x (no idea where they got those from.....) 6. Cheap N Nasty far east motherboards that had the ink removed and sold as Intel boards. (No offense - some of the best boards are made out there (Abit), but these were S*!t) 7. Usual fake Microsoft Mice. (These are VERY common) We got them in for 2 quid each, sold them for 16. 8. Sold OEM win95 licenses to anyone who wanted one (ie. without a new machine). Mind you, a lot of people do this..... 9. Fequently sold components that were knowingly stolen. 10. Faulty stock was found out to be faulty by selling it 3 times and if it was returned three times, then it was considered faulty.
You may think that is pretty bad, but it gets a whole lot worse. If a customer gave us a faulty machine to fix, and there was not any real problem (ie. Misconfiguration) then they would break the machine, and charge them for the component that was misconfigured. (eg. Couldn't get your CD-Rom to work under DOS madam? Im afraid it was broken. That will be 49.99 please) Their old CD-Drive was sold again in the following days. I am ashamed to admit I ever worked for this place. I resigned after 2 Months when they asked me to break a single mothers machine that was in for repair when there was nothing wrong with it. What gets me even more worked up is they fact that they got away with it. I quit over 3 years ago now, but they are still operating where I live (Edinburgh, Scotland) and have even moved to bigger premises to accomodate customer demand.
They guy who owns it made (in 1996) between 15 and 20K profit a week. As far as he was concerned it was a license to print money.
Please don't flame me for being nasty to local shops. I believe there are good local shops out there, and that they can get you a good deal. But be careful. VERY Careful.
One of the things I have noticed is that humans as a whole tend to remember pictures and symbols far more easily than alphanumeric information. (Simple fact - we have evolved that way). As one of the system administrators for a medium sized ISP, we are faced with the problem of regulary rotating certain account passwords (I think you can guess which ones;-) ). After several years it became hard to achieve unique ones that everybody involved could easily remember. Hence our switch to visual methods. Simple Example:-
Imagine a large smiley face situated on your keyboard (as in certain keys were colored differently to make up the face)
Nasty ASCII Art Bit:-
1234567890-= qwertyuiop[] asdfghjkl;'# zxcvbnm,./ Normal Keyboard layout
1234*6*890-= qwertyuiop[] as*f*h*kl;' \zxc**nm,./ Stars show keys used to draw smiley face
Ok, so I have made a pretty lame job of that, but notice that I have used 5 & 7 to make up the eyes, g for the nose and dvbj for the mouth. That gives us a password of 57gdvbj. Once we have that, we can add features to make it more secure, a Capital G for the nose for example, or using punctuation % and & to give the face "eyebrows". Personally I find this method a useful way of coming up with passwords that are only suseptable to brute force attacks, whilst maintaining a visual link so that our primate brains can have a stab at remembering them. Other pictures that can be used are symbols, flags, large letters, the list is pretty long.
Slashdot Mirror
Forgive me if I have this wrong, but if we start wiring houses for low voltage DC, won't this mean huge fat copper cables to deal with the current implications of a washing machine or oven pulling tens, even hundreds of amps because of Ohms law?
For data processing workloads, a frequent problem with GPU acceleration is that the working dataset size is too large to fit into the available GPU memory and the whole thing slows to a crawl on data ingest (physical disk seeks, random much of the time) or disk writes for persisting the results.
For folks serious about getting good ROI on their GPU hardware in real world scenarios, I strongly recommend you take a look at the fusion IO PCIe flash cards, which now support writing to and reading from them directly from CUDA via DMA, with little to no CPU handling required. (See: http://developer.download.nvidia.com/GTC/PDF/GTC2012/PresentationPDF/S0619-GTC2012-Flash-Memory-Throttle.pdf).
I can't talk about what we do with it, but lets just say the following hardware combination has lead to interesting results;
i) 16x PCIe slot chassis: http://www.onestopsystems.com/expansion_platforms_3U.php
ii) 8x Nvidia Kepler K20x's
iii) 8x Fusion IO 2.4TB IoDrive 2 Duo's
We have been able sustain over 4 million data operations a second, each one processing ~16 K of data in a recoverable, transactionally consistent manner, totaling up to around 50 Gigabytes of data processed per second. All in a 5U deployment drawing less than 4 kilowatts.
http://www.oracle.com/technology/products/bi/db/exadata/pdf/exadata-storage-technical-overview.pdf
Extremely valid point.
:) .
Not to bash Oracle, but the ultimate scalability of their multi-host database partitioning solution (RAC) is indeed limited by the amount of communication the distributed lock manager needs to make to ensure transactional isolation as the number of partitions/hosts increase. (Caveat to Oracle fans - 80% of requirements are beneath this threshold - so I understand Oracle's strategy.) (An alternative solution is the "shared nothing" partitioning approach (example - db2's DPF) but this has its own drawbacks too.)
I don't pretend for a second to know all the answers - indeed I suspect that some of them are yet to be invented/utilized effectively by industry.
My major point is that having distributed application side data caches will soon become very tempting in terms of the latency involved with accessing data. There are admittedly great challenges involved with doing this safely, in a way which is scalable as you point out and providing a productive application interface.
It will be very interesting over the next few years as we collectively work out the best approach to these requirements. Anybody can be wrong - me of all people - but my bet is that most of these problems will be solved. How they will be is the coolest part
You are right - it does.
The best methodology on how to efficiently and robustly manipulate large data sets in the application tier is still up for debate. In memory databases are but one potential solution to this requirement - there are many others. The javaspaces/gigaspace grid style solution is another.
Every current approach to this issue at present has is pros and cons - that's the price for being on the bleeding edge I guess.
What cannot be ignored is that we are on the edge of a potential paradigm shift - one powered by the fact that available system memory is about to surpass the size of the average state of a complex system. How this will effect our application design is still very much up for grabs, but be assured it will.
In my mind as a database engineer for a wall street bank, the biggest change in the near term that we forsee is data locality.
Given the amount of computing power on hand today, it may surprise many how difficult it is to engineer a system capable of executing more than a few thousand transactions per second per thread.
Why? Latency. Consider your average SOA application which reaches out to 4-5 remote services or dataserver calls to execute its task. Each network/rpc/soap/whatever call has a latency cost of anything between one and at worst several hundred milliseconds. Lets say for example that the total latency for all the calls necessary is 10 milliseconds. 1000/10=100 transactions per thread per second. Oh dear.
The amount of memory an "average" server ships with today is in the 32-64GB range. Next year it will be in the 64-128GB range. The average size of an OLTP database is 60-80GB.
So, the amount of memory available to the application tier will very soon be greater than the size of the database, warehouses excluded. Moore's law is quickly going to give the application tier far more memory than it needs to solve the average business state, exceptions noted.
The final fact in the puzzle is that for transaction processing, read operations outnumber write operations by roughly 20 to 1. (This will of course vary on the system, but that *is* the average.)
This situation is strongly in favor in migrating read only data caches back into the application tier, and only paying for the network hop when writes are done in the interests of safety. (There is a lot of research into how writes can be done safely asynchronously at the moment, but its not ready yet IMHO.)
Challenges exist in terms of efficient data access and manipulation when caches are large, performant garbage collection and upset recovery - but they are all solvable with care.
Its my opinion that in the near future large data caches in the application tier will become the norm. What has to be worked out is the most effective way of accessing, manipulating and administering that data tier and dealing with all the inevitable caveats of asynchronous data flow.
Some (not complete) examples of implementing this:
Relational Caches (there are many more):
http://www.oracle.com/technology/products/coherence/coherencedatagrid/coherence_for_java.html
http://www.alachisoft.com/ncache/index.html
Object Caches:
http://www.ogf.org/OGF21/materials/970/GigaSpaces_DataGrid_OGF_Oct07.ppt
http://jakarta.apache.org/jcs/
And second opinions here and here
I aggree with this - I find the architecture of Oracle very creaky - there is no clean abstraction of some of its components. This results in a "bolt on" feel.
;)
;)
Sybase ASE and Ms SQL have very clean system schemas - you get a feeling for how the system works just by looking at the relational diagram for them. (Ms have broken theirs a bit since they inherited ASE, but I digress.)
Oracle on the other hand is so non intuative that most of the useful system tables are really views to hide the real mess underneath...
That said, nobody can deny that once its up and running, the Oracle does work very well and is quite amazingly tolerant of poorly written SQL and Cursors. (Cursors IMHO break the whole relational idea, but I digress.) Its certainly its biggest strength after MVCC.
I really must find the time to look at Postgres or MySQL with the appropiate ACID moduled compiled in. Would people care to comment on how these look?
Amusingly enough, I too am now off to the bathroom..
This is very true.
;)
Other vendors out there don't get just how important this feature is.
In particular, Sybase ASE (which Microsoft SQL server is based on) *still* does not have this feature. Sybase's slant on it goes "If you design your system correctly, the fact that selects block updates does not matter in an OLTP system. Implementing MVC carries a significant overhead.". I have tried in vain for many years to convince them that:
a) The hard truth of the world is that very few systems are well designed. A good RDBMS should try and service even the worst of these.
b) Blocking lock strategies degrade very badly under load - the minute the system starts to slow down, the chance of blocking increases, which slows the system down further - see a repeating pattern here??
c) DSS style systems die without multi version control. Ever tried updating your system when somebody is running a 6 hour report against it?
I personaly don't like the Oracle product itself (its architecture from a DBA's perspective is a dogs breakfast compared to Sybase ASE, IBM's UDB/DB2, Informix or Ms SQL server), but this feature alone makes it perform far better that any of these in most real world situations.
Why other competitiors don't get this is beyond me...
Rant over.
Post on halflife2.net from Gabe Newell:
Ever have one of those weeks? This has just not been the best couple of days for me or for Valve.
Yes, the source code that has been posted is the HL-2 source code.
Here is what we know:
1) Starting around 9/11 of this year, someone other than me was accessing my email account. This has been determined by looking at traffic on our email server versus my travel schedule.
2) Shortly afterwards my machine started acting weird (right-clicking on executables would crash explorer). I was unable to find a virus or trojan on my machine, I reformatted my hard drive, and reinstalled.
3) For the next week, there appears to have been suspicious activity on my webmail account.
4) Around 9/19 someone made a copy of the HL-2 source tree.
5) At some point, keystroke recorders got installed on several machines at Valve. Our speculation is that these were done via a buffer overflow in Outlook's preview pane. This recorder is apparently a customized version of RemoteAnywhere created to infect Valve (at least it hasn't been seen anywhere else, and isn't detected by normal virus scanning tools).
6) Periodically for the last year we've been the subject of a variety of denial of service attacks targetted at our webservers and at Steam. We don't know if these are related or independent.
Well, this sucks.
What I'd appreciate is the assistance of the community in tracking this down. I have a special email address for people to send information to, helpvalve@valvesoftware.com. If you have information about the denial of service attacks or the infiltration of our network, please send the details. There are some pretty obvious places to start with the posts and records in IRC, so if you can point us in the right direction, that would be great.
We at Valve have always thought of ourselves as being part of a community, and I can't imagine a better group of people to help us take care of these problems than this community.
Gabe
__________________
Gabe Newell
I am beginning to wonder when apple will be brave enough to release what has to be the "killer" 802.11 application for mp3 players - personal streaming.
l
;)
Just imagine how cool it would be to share your music and playlists with any other ipod user within range. Tired of your own collection? Try listening to Bob's ipod 4 seats behind you.
The register has also thought about this - http://www.theregister.co.uk/content/39/28467.htm
What do people think? I would love this, but there are - erm - interesting legal aspects..
On a secondary note - does anybody know where you can source an audrey from the UK?
Tigerdirect will not ship them here due to problems with customs...
Thanks!
Dave.
This is without a doubt of the more impressive HCI developments I have seen in the last decade, and steady progress is being made.
I note that progress is also beging made in the reverse process (generating an image by monitoring neurons firing in the visual cortex). Check out this paper:-
Visual Decoding
Which details images generated directly from a cats brain.
One point to keep in mind is that sadly this technology can only help people whom had sight at birth, but lost it after early childhood. If the patient has been blind from birth, the parts of their brain that would be normally used for vision have not developed and have been "reassigned" to other sensory tasks. (Which is why blind people tend on average to have more actue senses of hearing, smell, touch and taste - there are more neurons available to process them!) If this device was deployed on such a person, it is doubful that they could make much sense of what they could "see".
Just a sidenote - in Europe (well - London) Nestle already sell similar cans of self heating coffee. Works quite well - shame about the taste of whats in the can though. I can't remember the reactants - but the oxidser is diluted hyrogen preoxide.
All the 30 first stage motors are identical Kuznetsov Design Bureau NK-33's generating 154 metric ton's of thrust each.
There is a lot of debate about why the Soviets chose this approach, but for me its a combination of three reasons:-
a) Previous Soviet Rockets were also based on the "many small engines" approach - they worked fine. (Even if it was not the most efficient approach)
b) A key reason the the N-1 ended up with 30 NK-33 engines instead of something more manageable was political infighting. The Soviet chief engine disigner Glushko had an intense argument over fuel choice with the N1 designer Korolov and ended up taking experience to the Soviet military with the UK-500 and 700 boosters. That left Korolov with no engine designer and in the end the N-1 had it's engines designed from existing templates.
c) At the time there were real doubts over the feasibility of combistion stability in engines with large injector surfaces. (Ie - large engines). It took Rocketdyne many, many tests to get the F-1 to work. The Soviets felt that developing these large engines was simply too risky (and expensive), despite the obvious efficiency gains.
Hi All,
Quick question - does anybody have a source of Audreys in the UK? I can't seem to find anybody still selling them. (The US web sites are not that keen on shipping them internationally....)
Thanks!
I can't believe I am just about to platform bash, but:-
:) )
:-)
Please don't rule out Sybase for large systems. I work for a large investment bank, and we use both Sybase and Oracle heavily. (As you would imagine a bank might..
Whilst Oracle does have the edge for indexing extremely large DSS systems (bitmap indexing..) Sybase is more than capable of holding its own - even for tables >20Gb in size with rowcounts in the tens of millions. People tend to forget just how much cheaper than Oracle Sybase is - IMHO it offers much more bang for buck...
If only its technical support in the UK did not suck rocks most of the time...
Ah well, Rant over.
Assuming the reports are accurate, the only reason these guys/gals are successful in these schemes is because there are people out there naueve enough to fall for their social attacks.
:(
Yes, they did work the system, but I don't see anything here to be worried over - people will simply have to learn that you don't give your credit card details out on a whim...
The only thing that does concern me is that people like this provide the powers at be the perfect excuse to attack anonimity...
Ah well - rant over.
Scene:-Computer Lab Student: Excuse me, but what is the command for deleting a directory and all its subtrees? Lab Technician: rm -rf Student: Are you sure? Lab Technician: Yes On a serious note, as voice enabled computer technology becomes more common, what standards are there to enable us to seperate computer commands from normal conversation? Do we have to be like ST and prefix everyhting with "computer", or are there more intelligent ways?
1. Eye Strain. Display technology is making leaps and bounds, but I STILL feel a bit odd after looking at a computer screen of more than a few hours. Manuals can place a bit of variety in this. ;-)
2. The "Bog" factor. Manuals can go *many* places a computer/laptop couldn't. Be it bed/toilet/train.
3. The multiplicity factor. If my desk is big enough, I can have 4 manuals open at the same time and cross reference between them. This can be very useful at times - try doing this on a 14" monitor.
4. The failure factor. If all else fails, and my system goes down in flames, the paper manual will still be there.
That said, there are a *lot* of advantages of having "online" manuals. I predict that "online" manuals will eventually phase out the paper ones, but only when the following conditions are met, negating my previous gripes.
1. When display technology gets good enough for me not to notice the difference between laser printed paper ( >600 dpi) and a VDU (be it LCD, LEP - whatever)
2. When there exists computer systems that are light, convienent and rugged enough to survive as well as paper manuals in various places. I suppose an advanced enough "e-book" style device might do here.
3. When the aforementioned "e-book" systems are cheap enough for me to have multiple units.
4. The "e-book" systems *have* to be extremely reliable - no running out of batteries at the wrong time, etc. etc.
Its only when these, and more, conditions are met will we see the phasing out of the demand for paper manuals. That said, I think we will have the change forced upon us before that time, simply because its a way for the software companies to save a few pence. *sigh* Time to get new glasses....;-)
a) To prevent access to foreign "propoganda" sites that might encourage China's citizen's to become more resistant to the Communist Party's wishes. (It would appear that they consider the New York Times to be one.
b) To prevent the orginaisation of grassroot political groups via the internet.
Anyone here will know that a) is simply impossible. Sites can change URL's in a matter of minutes, multiple mirrors etc etc. (We need only look at how poor some of the existing "censorship" products are in the West to realise that what China's government want to do is extremely difficult.)
They do however, have a better chance at preventing b), with possible human rights implications. The article states that the only ISP in China is run by the government. Since they control the remote access equipment, it would be fairly trivial not to stop someone from sending "undersirable" material, but to find out whom did. (eg. Search google one too many times about democracy and you might have a surprise visit from the local army squad.) Presumably the use of encryption would also render you immediately suspect.
It will be interesting to see how this one develops...
As has been said in previous comments, the Wing In Ground effect is something that has actually been known about for some time. (The first evidence came from the Pilots of early Dornier flying boats.) I have found a site that deals with this effect, and the aircraft that have exploited it at:- http://www.io.tudelft.nl/~twai o/edwin/html/index.htm
We all know how well Linux performs on mid range to low end hardware. (I run 2.2 on mid range Dell Poweredges and a am very pleased with its performance.)
;-) )
However, various recent benchmarks and editorials have pointed out Linux'es problems when it comes to perfroming well on high end servers. If memory serves me correct, this was mainly due to the SMP support in the 2.2 kernel and the TCP/IP stack, along with other problems with device drivers. (eg. Ethernet Card). It was my understanding that the kernel SMP support was being re-written for 2.4 to address some of the shortcomings and to help performance in general on high end machines.
So my question is, how much actually has been done in the 2.3/2.4 tree to address these performance issues? (Feel free to correct me if anything I have said here is wrong - but then you would probably do that anyway
Thanks for your time!
It is a sad fact, but a lot of these local stores will quite happily ripoff anyone if they think they can get away with it. I know, I used to work for one. Common tricks were (in the olden days):-
1. Removing the print on 486's/Pentiums and reprinting them as the next model up. (They sadly got away with this 99.99% of the time - the systems were soak tested before delivery)
2. 66 Mhz Ram for 100 Mhz (again, got away with it all the time - how to YOU know your memory is 100Mhz??? V.Hard to tell. I left before the days for 100Mhz RAM, but I know someone that works there still)
3. For our own systems we had a hacked BIOS image that reported standard SIMMS as EDO, when they were just FPM.
4. Some HDD Manufacturers used to sell drives that had failed some QC test on the cheap. (I don't believe they do anymore). We used to have low level format utilities that would format a 2BG drive full of bad sectors into a 1.6GB drive. We would then sell them.
5. Got Mutsumi 6x cd-drives that reported themselves as 8x (no idea where they got those from.....)
6. Cheap N Nasty far east motherboards that had the ink removed and sold as Intel boards. (No offense - some of the best boards are made out there (Abit), but these were S*!t)
7. Usual fake Microsoft Mice. (These are VERY common) We got them in for 2 quid each, sold them for 16.
8. Sold OEM win95 licenses to anyone who wanted one (ie. without a new machine). Mind you, a lot of people do this.....
9. Fequently sold components that were knowingly stolen.
10. Faulty stock was found out to be faulty by selling it 3 times and if it was returned three times, then it was considered faulty.
You may think that is pretty bad, but it gets a whole lot worse. If a customer gave us a faulty machine to fix, and there was not any real problem (ie. Misconfiguration) then they would break the machine, and charge them for the component that was misconfigured. (eg. Couldn't get your CD-Rom to work under DOS madam? Im afraid it was broken. That will be 49.99 please) Their old CD-Drive was sold again in the following days.
I am ashamed to admit I ever worked for this place. I resigned after 2 Months when they asked me to break a single mothers machine that was in for repair when there was nothing wrong with it.
What gets me even more worked up is they fact that they got away with it. I quit over 3 years ago now, but they are still operating where I live (Edinburgh, Scotland) and have even moved to bigger premises to accomodate customer demand.
They guy who owns it made (in 1996) between 15 and 20K profit a week. As far as he was concerned it was a license to print money.
Please don't flame me for being nasty to local shops. I believe there are good local shops out there, and that they can get you a good deal. But be careful. VERY Careful.
One of the things I have noticed is that humans as a whole tend to remember pictures and symbols far more easily than alphanumeric information. (Simple fact - we have evolved that way). ;-) ). After several years it became hard to achieve unique ones that everybody involved could easily remember. Hence our switch to visual methods.
As one of the system administrators for a medium sized ISP, we are faced with the problem of regulary rotating certain account passwords (I think you can guess which ones
Simple Example:-
Imagine a large smiley face situated on your keyboard (as in certain keys were colored differently to make up the face)
Nasty ASCII Art Bit:-
1234567890-=
qwertyuiop[]
asdfghjkl;'#
zxcvbnm,./
Normal Keyboard layout
1234*6*890-=
qwertyuiop[]
as*f*h*kl;'
\zxc**nm,./
Stars show keys used to draw smiley face
Ok, so I have made a pretty lame job of that, but notice that I have used 5 & 7 to make up the eyes, g for the nose and dvbj for the mouth. That gives us a password of 57gdvbj. Once we have that, we can add features to make it more secure, a Capital G for the nose for example, or using punctuation % and & to give the face "eyebrows".
Personally I find this method a useful way of coming up with passwords that are only suseptable to brute force attacks, whilst maintaining a visual link so that our primate brains can have a stab at remembering them. Other pictures that can be used are symbols, flags, large letters, the list is pretty long.
Good Idea/Bad Idea?
Dave.