You spent two weeks thinking up a domain name and now can't remember it?
Man, you must have a terrible memory. Did you spend the entire two weeks going "I need a good domain name... how about awesome.net? Nah, that's no good. How about awesome.net? Yes, that's it!":)
I think up a lot of domain names. I have lots of ideas.
It was 5-15 minutes a day.
My ad hoc method gets me very good domains.
I want you to try to think up a domain name with only dictionary words and see how well you do. Big talk from an anonymous weenie.
I have a list of a few hundred potential domain names. It's something I do, so if you can remember 1 name out of several hundred that you wrote down a year ago, great for you then.
I believe you're a big fat turd with sausage fingers, given you hide behind anonymous to shield your real username.
I don't think it'd work. It'd be very easy to load them into a table, filter them against dictionary words, and sort them by # of hits.
Human eyeballs could pull the top 1000, do a quick spot check on the list, remove garbage names, and register the rest. Once setup, it'd take about 10-15 minutes of human intervention a day.
A year ago I searched on a domain I had spent 2 weeks thinking up. It was available but I waited 3 days. When I went to purchase, it was registered 1 or 2 days before. At the time I chalked it up to bad luck.
I only wish I could remember the domain name. I might have it in my notes but I have pages and pages of notes.
Sometimes your options are a 1 to 1.5 hour connection or an 8 hour connection.
If the ticket is booked all the way through on one itinerary, then they have to get you to your destination. So, I'm less worried about missing the connecting flight than I am about losing my luggage. I know I will get there. I'm uncertain if my luggage will.
So, having my luggage come off first/last, I don't think anyone is EVER in that hurry, even if you are multibillion CEO.
You are if you're flying international and transiting through LAX. They don't check your bags straight through anymore. You have to pull them off the carousel in LAX now. That is tough if your connecting flight is a close one.
3. Planeside check on your outward trip. This ensures the baggage monkeys don't lose your luggage. If you failed to follow tip #1, and you must check your bag, be sure you carry with you the basics for an overnight stay.
What are you smoking? You can't even get near the terminal with large check-in bags with security. We don't live in 1990 anymore.
People generally don't really buy such "specialty gaming peripherals", especially not the mass gaming market.
I think any new game device needs to be supported or bundled with the current killer game in order to be adopted. Most of these devices aren't on the radar because they're so niche and their audience is so small.
I also think a lot of the ones that didn't catch on weren't quite ready. They reeked of prototypinitus; clunky, very expensive, and didn't really add any improved means of controlling or sensing.
The vest seems interesting though.. and it's not a bad opening price.
sorry web design is not nearly as difficult as many make it out to be. Some of the cumbersome tools and even client requirements can make it work - but its not like writing the back end that serves these pages or runs the business.
I've done both: server work and front end web design. The difficult part of server work is usually integration with other systems as well as designing for performance. There are two back-ends: the internal architecture that encompasses your database, support scripts, and custom server code, and then there is the CGI layer, which queries and formats the data for presentation. The easy part of back-end work is with CGI scripts, which is the link between the real back-end and the front-end (browser). Writing CGI scripts to serve those pages is stupid simple, usually performed by junior developers, so it's not like all back-end work is touchable only by the resident genius guru.
Your insulting comment is correct in that parts of web design work is easy. Processing images, slicing pages, and uploading them is quite easy, but so is writing a CGI form that gathers a user's information and inserts a record into a database. The difficult part of web design is with managing the information architecture of the site, integrating various applications and their project files, as well as dealing with browser and CSS idiosyncrasies. Those aspects are similar to database architecture, systems integration and project files, and dealing with operating system and language idiosyncracies. It's not surprising to me that the difficult parts of both happen to be logically very similar.
The reason web designers are paid less is due to the fact it's a creative and desirable job, so more people are going to apply. It's also a field in which your portfolio makes or breaks you. You are judged quite heavily on the visual quality of your work. Producing visually stunning output, does does not mean you're a HTML/CSS/Javascript god. The problem with this scale of judgment is that it's based on what a manager sees. You and management see a nice illustration and you drastically under-estimate how time consuming creating that illustration can be. Of course, you don't try to reproduce it yourself and find out, but you judge anyway.
Software developers are judged with a different scale, which is generally work experience and education level. You aren't judged by the quality of your code*. You get to hide behind the cloak of mystery, safe in the knowledge management will never see or understand your work. Management only sees whether your product performs the task it's supposed to do or not. It could be an architectural nightmare slapped together with a fragile hodge-podge non-framework--a spaghetti code mess. But, do you lose income if you produce such a colossal piece of shit? No. You get a raise because you "optimized" a query to return results back in 2 seconds instead of the 10 seconds as before.
Web pages are not critical.
Which, you posted using a web page. Irrelevant, but funny.
What does amaze me is how long they can take to deliver certain changes, the only thing slower are C++ programmers on our pc based servers.
Maintenance changes to the back-end often follows along the lines of adding a new column or table to the database, so it's not like those changes you make are all that complicated to begin with.
60K low? Yeah, if they were a C++ programmer or programmer in a real language on a mini or mainframe.
Difficulty is relevant. If you're a mainframe developer, you are expected to know your trade. Lots of people can't do what you can do; accountants, lawyers, salesman, delivery boys, etc. Big deal. I know what you do is not that difficult. I've done work in assembler and writing network server processes that many consider "difficult", but in truth it wasn't. Knowing how to do it doesn't make me smarter than a we
Moreover, while I can understand this would make most women uncomfortable in the workplace, I can also vouch for my experience in offices staffed predominantly by females--it's very uncomfortable for the few men, at that point.
I think it would make women uncomfortable. Cursing is often associated with anger, and anger with violence. Women are not fond of hanging around cursing, angry, violent men--even if it's not an accurate portrayal of what the man is thinking. What matters is the outward expression.
You can't code around having a small amount of RAM and still maintain high performance.
I wouldn't agree with that. That's only true if the algorithm relies on access to the entire data set because it requires random access or multiple table scans. Lots of algorithms can operate on small independant chunks or can be rewritten to use sequential data access, which is chunk friendly. I think it's apparent his algorithm works on small chunks due to the relatively small amount of RAM, unless his entire data set fits within 256MB. Either way, the fact it's working for him implies the answer.
Now, a lot of it is influenced on whether records are accessed once or multiple times. If it's once, the overhead is the same as loading it all up in memory and running computation on the entire data set, because there's 1 chunk read per access for N reads per N accesses. If the algorithm has to revisit chunks, then you've potentially got >N reads per N accesses (assuming a caching scheme is used), which kills performance if you're swapping chunks in and out or rescanning the data set from the beginning.
So in summary, high performance is possible with "smallish" amounts of RAM if the following is true:
Chunks are independant. Results are not passed as input for processing the next chunk.
Algorithm is CPU bound, not IO bound.
1 time sequential access: optimized by prefetching.
This kind of language is what [African] applicants for US visas face when denied US visas at the many US visa posts across the continent. I guess it cuts both ways.
The thing is, when Americans say it to them, Nigerians get pissed. When they say it to Americans, Americans laugh.
For my money, getting a 5w computer is kinda pointless when I'm expected to hook it up to a desktop LCD which could easily use more than 10 times that much power.
The monitor powers down when idle though.... so it's not 10* times greater consumption unless you use the PC 24 hours a day. Besides, 165 watts (my lcd monitor) + 5 (pc) = 170 watts is still considerably less than 415 watts = 165 + 250.
Anyway. I'd be more interested in this fitPC if it had considerably more RAM.. say 512 or 1G.
The problem is tribal war, yet their solution is a cook stove put together from scrap metal. These feel good do nothing fluff solutions really make the western world look like a bunch of assholes.
... is exactly what Wiki doesn't need. Those policies were developed to keep Wiki from becoming a short lived blog.
It doesn't help if that potential new editor is an expert in the topic and gives up due to procedural complexity. There's nothing wrong with throwing hurdles in the path of a new editor; however, when the hurdles are bureaucratic fuzz and duplicate procedures with slight variations, it's rather demotivating. Hurdles should be purposeful, not accidental.
If a bit flips in your video RAM, a pixel is going to be bad or a texture will be slightly different. You're not going to notice.
What if that bit flipped is in the data structure that defines a collection of of surfaces? How about when the bit flipped is in header data for a texture image? A 100x100 pixel texture now reads as 2,147,483,748x100 pixels. Wonder what happens when that corrupted texture is swapped out for another texture. Ouch.
Yea. I'm sure you'll hardly noticed when the rendered scene looks like a bunch of garbled noise.. or your video driver is blue screening your box.. or the GPU is off in la-la land munching away on bad data. Not all the memory is used for the frame buffer.
Years ago, I tested static HTML vs. PHP by simply benchmarking a simple document (I used the GPL license). On the particular box, I was able to serve over 400 pages per second with static HTML but only about 12 pages per second with PHP. I was blown away. I went one step further and used PHP to fetch the data from Oracle (OCI8, IIRC) and that went down to 3 requests/sec. You can see that caching does help, but not a whole lot.
12 page/sec eh? You didn't put a busy wait in there did you? I've never seen performance that slow with PHP on a production server even with 2 or 3 SELECTs on a database, without APC, and without DB pooling (per request). Either that was a very large number of years ago or your server was a real piece of shit.
On Apache/Linux, I've seen jumps from 75-90 req/sec to about 250-400 req/sec with a PHP CGI by just adding APC. It was on a fairly fast multi-core machine (2 or 4, can't remember). It's been my experience that PHP compilation is the 2nd heaviest performance hit (opening database connections would be 1st).
Slashdot Mirror
Hmmm. An apology. WOW.
Okay, I'll retract my big fat turd comment. But, the sausage finger one still holds.
Poisoning with dictionary domains would have more potential to mess with them...
I don't think it'd work. It'd be very easy to load them into a table, filter them against dictionary words, and sort them by # of hits.
Human eyeballs could pull the top 1000, do a quick spot check on the list, remove garbage names, and register the rest. Once setup, it'd take about 10-15 minutes of human intervention a day.
Now you tell us. :D
A year ago I searched on a domain I had spent 2 weeks thinking up. It was available but I waited 3 days. When I went to purchase, it was registered 1 or 2 days before. At the time I chalked it up to bad luck.
I only wish I could remember the domain name. I might have it in my notes but I have pages and pages of notes.
...why not just put the OS on the GPU and use the CPU for mundane things? :)
Method Not Allowed
An error has occurred.
I also think a lot of the ones that didn't catch on weren't quite ready. They reeked of prototypinitus; clunky, very expensive, and didn't really add any improved means of controlling or sensing.
The vest seems interesting though.. and it's not a bad opening price.
I've done both: server work and front end web design. The difficult part of server work is usually integration with other systems as well as designing for performance. There are two back-ends: the internal architecture that encompasses your database, support scripts, and custom server code, and then there is the CGI layer, which queries and formats the data for presentation. The easy part of back-end work is with CGI scripts, which is the link between the real back-end and the front-end (browser). Writing CGI scripts to serve those pages is stupid simple, usually performed by junior developers, so it's not like all back-end work is touchable only by the resident genius guru.
Your insulting comment is correct in that parts of web design work is easy. Processing images, slicing pages, and uploading them is quite easy, but so is writing a CGI form that gathers a user's information and inserts a record into a database. The difficult part of web design is with managing the information architecture of the site, integrating various applications and their project files, as well as dealing with browser and CSS idiosyncrasies. Those aspects are similar to database architecture, systems integration and project files, and dealing with operating system and language idiosyncracies. It's not surprising to me that the difficult parts of both happen to be logically very similar.
The reason web designers are paid less is due to the fact it's a creative and desirable job, so more people are going to apply. It's also a field in which your portfolio makes or breaks you. You are judged quite heavily on the visual quality of your work. Producing visually stunning output, does does not mean you're a HTML/CSS/Javascript god. The problem with this scale of judgment is that it's based on what a manager sees. You and management see a nice illustration and you drastically under-estimate how time consuming creating that illustration can be. Of course, you don't try to reproduce it yourself and find out, but you judge anyway.
Software developers are judged with a different scale, which is generally work experience and education level. You aren't judged by the quality of your code*. You get to hide behind the cloak of mystery, safe in the knowledge management will never see or understand your work. Management only sees whether your product performs the task it's supposed to do or not. It could be an architectural nightmare slapped together with a fragile hodge-podge non-framework--a spaghetti code mess. But, do you lose income if you produce such a colossal piece of shit? No. You get a raise because you "optimized" a query to return results back in 2 seconds instead of the 10 seconds as before.
Which, you posted using a web page. Irrelevant, but funny.
Maintenance changes to the back-end often follows along the lines of adding a new column or table to the database, so it's not like those changes you make are all that complicated to begin with.
Difficulty is relevant. If you're a mainframe developer, you are expected to know your trade. Lots of people can't do what you can do; accountants, lawyers, salesman, delivery boys, etc. Big deal. I know what you do is not that difficult. I've done work in assembler and writing network server processes that many consider "difficult", but in truth it wasn't. Knowing how to do it doesn't make me smarter than a we
Now, a lot of it is influenced on whether records are accessed once or multiple times. If it's once, the overhead is the same as loading it all up in memory and running computation on the entire data set, because there's 1 chunk read per access for N reads per N accesses. If the algorithm has to revisit chunks, then you've potentially got >N reads per N accesses (assuming a caching scheme is used), which kills performance if you're swapping chunks in and out or rescanning the data set from the beginning.
So in summary, high performance is possible with "smallish" amounts of RAM if the following is true:
Anyway. I'd be more interested in this fitPC if it had considerably more RAM.. say 512 or 1G.
* It's actually more like 20-40 times.
To the person who modded me Flamebait, my URL pic is for you.
The problem is tribal war, yet their solution is a cook stove put together from scrap metal. These feel good do nothing fluff solutions really make the western world look like a bunch of assholes.
Yea. I'm sure you'll hardly noticed when the rendered scene looks like a bunch of garbled noise.. or your video driver is blue screening your box.. or the GPU is off in la-la land munching away on bad data. Not all the memory is used for the frame buffer.
Naahhhh. Couldn't be!
On Apache/Linux, I've seen jumps from 75-90 req/sec to about 250-400 req/sec with a PHP CGI by just adding APC. It was on a fairly fast multi-core machine (2 or 4, can't remember). It's been my experience that PHP compilation is the 2nd heaviest performance hit (opening database connections would be 1st).