It has a limit to the number of writes, the number of reads is pretty unlimited. The expected average lifetime is similar to a hard drive, and in some cases better.
I don't believe that at all. I have read the opposite - that flash wear for high-write systems, like a server - is very rapid, in fact Dell is getting returns for flash workstations at a rate faster than any other computer. You might be right, can you post a few links?
For high availability clustered web applications, it's not disc IO that is the problem, but network overhead.
I tend to use log4j and asynchronous logging that passes log messages to a syslog server that can handle the file io - and it ends up being network overhead that is the killer.
Oh yea, and their new iPhone is a great toy, nice fun! But in the work world where I have a job to do - F the iPhone. It's a great fun toy - but fails to do important stuff, you know, like handle phone calls well. http://www.businessweek.com/magazine/content/08_34/b4097000494697.htm
To bad their software stack is closed, buggy and radically insecure! It's a great consumer toy, but for real work - it's PC and Linux. I'd rather have a beige box, save a grand, and have better software. (xp, mind you, vista blows)
If any of your general (even technical) employees can execute a select statement and get credit card information, you are screwed. For small company, flush your credit card numbers as soon as you are done processing the transaction. (do not log them or persist them in any way)
If you are a big company and really need to store credit cards beyond the transaction time, you are under the umbrella of PCI. PCI says you need to encrypt and isolate credit card data in a secure repository - where only a few trusted (and heavily background checked) employees have access.
"Cryptography in the database" by symantec press is a good software-code-centric book on the topic. If you org cannot afford to build a solution to isolate and encrypt data in this regard, then you should not be storing it.
Social Security, health, financial transaction records - they should all be dealt with in this form. The days of storing sensitive information plain text in a database are over.
Not me, I have been on vacation away from my computer. I did note that Steve Jobs announced that he was clear of cancer and Apple stock went up 3% right away (read it in a newspaper). Reading this made me think fondly of you. Money talks, I might be wrong about dear Steve.
NBC did not renew their content agreement with Apple back in August 07. NBC moved to Hulu and other methods of distribution. Even Colbert/John Stewart, (big vid sellers for apple) while still selling on iTunes, also offer free version of their show on comedy centrals website. In this poor economy, Apples focus on the consumer space will seriously hurting it in the upcoming months - regardless of the iPod market share - iPod sales are expected to peak or decline (most likely why iPod sales figures for q208 are not reported yet)..
In come the iPhone - it's critical for Apples continued growth. It's so close to competing with the blackberry, that I think a more business-friendly leader would be better suited to guide Apple for a time.
Apple is doing great things - Jobs has done good resuscitating Apple these past many years. I think more business savvy leadership is necessary to sustain the growth. Consumer spending is going to be a problem for the next couple of years.
Again, I'm sorry to insult your fanboihood. Steve Jobs does not treat his employees with enough respect and pay. I also believe he is a poor spokesperson for the new non-fanatic consumer-centric population that is being attracted to the brand. Steve's attitude is also harming his ability to partner with content organizations (ie: losing NBC). He also made a very bad call w/ ATT, IMO (very poor 3g network). Apple is getting a too big for Steve to handle.
Sorry to upset your fanboihood. Apple is in a very good place - Jobs has done a great job getting the company back on track. He zealous/cutthroat/scumbag nature was for the good of the company. It's not needed anymore. Any of his lieutenants can take the helm and sail the ship from here.
I do not wish any ill will to Steve Jobs. But he still is a scumbag. He treats almost all of his employees like crap. He underpay his engineers - one of the worst paying companies at that level. He is a rude obnoxious bastard. Great ideas, but horrible person. I think Apple will be better off without him.
Your smarmy little comments were not necessary. My original code stating that the userId from the request needed to be a positive integer that matched the current user in session illustrated that this is a simple problem to solve.
Dude, I was writing pseudo-code. Stop being an asshole. The point I was making is that the code to solve an issue of this nature is trivial; I was not trying to make it perfect, hence the term pseudo-code.
However, I agree with you 100% that the administrative utility should be separated from the normal user account, and therefor the standard user page would only need to grab the userid from the session. You point well taken.
Also be wary of RBAC calls like user.isSuperUser(). Most productizied/enterprise applications really mandate data-layer-access control calls like:
user.hasAccess(entity, function);
If you start hard-coding roles into your application and need to change that policy, you will need to change code. But if you make calls like:
user.hasAccess(Organization(2), "editOrg");
you can then change your access control policy without needing to change code.
In order for a superuser to view or take over a specific user account; that superuser will need to select a user to view via some kind of request parameter.
Good point, I do agree with you that the userId should be taken out of the request and just pulled from session in many cases.
However, the userId might need to be implemented from the request as I have described in case you want to support administrative features where a superuser can access any account. That is why code of this nature is so common.
Slashdot Mirror
It has a limit to the number of writes, the number of reads is pretty unlimited. The expected average lifetime is similar to a hard drive, and in some cases better.
I don't believe that at all. I have read the opposite - that flash wear for high-write systems, like a server - is very rapid, in fact Dell is getting returns for flash workstations at a rate faster than any other computer. You might be right, can you post a few links?
For high availability clustered web applications, it's not disc IO that is the problem, but network overhead.
I tend to use log4j and asynchronous logging that passes log messages to a syslog server that can handle the file io - and it ends up being network overhead that is the killer.
> So, you're a fan of plastic crap, as long as it's not overpriced
Yes, indeed! I have a flock of pink flamingos on my front lawn that I got from the dollar store! wooooooooooooo!
Oh yea, and their new iPhone is a great toy, nice fun! But in the work world where I have a job to do - F the iPhone. It's a great fun toy - but fails to do important stuff, you know, like handle phone calls well. http://www.businessweek.com/magazine/content/08_34/b4097000494697.htm
Oh yea, and can actually play decent games on my under $1k pc. Solid games, like cod4, crysis, etc. F apple.
To bad their software stack is closed, buggy and radically insecure! It's a great consumer toy, but for real work - it's PC and Linux. I'd rather have a beige box, save a grand, and have better software. (xp, mind you, vista blows)
You can be not-evil yet still (wooops!) be forced into doing evil things buy powers greater than you. That is the key distinction.
Apple only spends $292 on R&D? No wonder all their shit is overpriced plastic crap!
I don't agree - the poster is smart to want the entertainment audio to *forcibly, automatically* lower when his (money making) phone call arrives.
Does slashdot do any kind of link validation, possibly rejecting links to malware and the like?
If any of your general (even technical) employees can execute a select statement and get credit card information, you are screwed. For small company, flush your credit card numbers as soon as you are done processing the transaction. (do not log them or persist them in any way)
If you are a big company and really need to store credit cards beyond the transaction time, you are under the umbrella of PCI. PCI says you need to encrypt and isolate credit card data in a secure repository - where only a few trusted (and heavily background checked) employees have access.
"Cryptography in the database" by symantec press is a good software-code-centric book on the topic.
If you org cannot afford to build a solution to isolate and encrypt data in this regard, then you should not be storing it.
Social Security, health, financial transaction records - they should all be dealt with in this form. The days of storing sensitive information plain text in a database are over.
Why did the DA even have access to these passwords? Why were they not in hash form? Did Child's have anything to do with that part?
Hash form is not enough; might as well be plaintext for up to 10 or more characters. They need to be in *per-user salted* hash form.
Can't win with you. Argh! I can't wait til I get more mod points....
It's your site, your server you code. You have a small peaceful community. Just delete his account and move on.
Not me, I have been on vacation away from my computer. I did note that Steve Jobs announced that he was clear of cancer and Apple stock went up 3% right away (read it in a newspaper). Reading this made me think fondly of you. Money talks, I might be wrong about dear Steve.
You are the wind beneath my wings. That was my most favorite Slashdot post, ever.
NBC did not renew their content agreement with Apple back in August 07. NBC moved to Hulu and other methods of distribution. Even Colbert/John Stewart, (big vid sellers for apple) while still selling on iTunes, also offer free version of their show on comedy centrals website. In this poor economy, Apples focus on the consumer space will seriously hurting it in the upcoming months - regardless of the iPod market share - iPod sales are expected to peak or decline (most likely why iPod sales figures for q208 are not reported yet) ..
In come the iPhone - it's critical for Apples continued growth. It's so close to competing with the blackberry, that I think a more business-friendly leader would be better suited to guide Apple for a time.
Apple is doing great things - Jobs has done good resuscitating Apple these past many years. I think more business savvy leadership is necessary to sustain the growth. Consumer spending is going to be a problem for the next couple of years.
Again, I'm sorry to insult your fanboihood. Steve Jobs does not treat his employees with enough respect and pay. I also believe he is a poor spokesperson for the new non-fanatic consumer-centric population that is being attracted to the brand. Steve's attitude is also harming his ability to partner with content organizations (ie: losing NBC). He also made a very bad call w/ ATT, IMO (very poor 3g network). Apple is getting a too big for Steve to handle.
PS: Sorry if I insulted you earlier.
PPS: Fuck you.
Sorry to upset your fanboihood. Apple is in a very good place - Jobs has done a great job getting the company back on track. He zealous/cutthroat/scumbag nature was for the good of the company. It's not needed anymore. Any of his lieutenants can take the helm and sail the ship from here.
I do not wish any ill will to Steve Jobs. But he still is a scumbag. He treats almost all of his employees like crap. He underpay his engineers - one of the worst paying companies at that level. He is a rude obnoxious bastard. Great ideas, but horrible person. I think Apple will be better off without him.
Your smarmy little comments were not necessary. My original code stating that the userId from the request needed to be a positive integer that matched the current user in session illustrated that this is a simple problem to solve.
> causes the whole server to exit.
Dude, I was writing pseudo-code. Stop being an asshole. The point I was making is that the code to solve an issue of this nature is trivial; I was not trying to make it perfect, hence the term pseudo-code.
However, I agree with you 100% that the administrative utility should be separated from the normal user account, and therefor the standard user page would only need to grab the userid from the session. You point well taken.
Also be wary of RBAC calls like user.isSuperUser(). Most productizied/enterprise applications really mandate data-layer-access control calls like:
user.hasAccess(entity, function);
If you start hard-coding roles into your application and need to change that policy, you will need to change code. But if you make calls like:
user.hasAccess(Organization(2), "editOrg");
you can then change your access control policy without needing to change code.
In order for a superuser to view or take over a specific user account; that superuser will need to select a user to view via some kind of request parameter.
Good point, I do agree with you that the userId should be taken out of the request and just pulled from session in many cases.
However, the userId might need to be implemented from the request as I have described in case you want to support administrative features where a superuser can access any account. That is why code of this nature is so common.
userId = checkInt(userId);
should be
userId = checkInt(sUserId );
This code checks that the userId from the request matches the current authenticated user in session. Thanks for your asshole comment. Have a nice day.