That makes logical sense but that is not how the terms are used in industry. MLC actually means two levels and TLC is three. QLC will be the term to describe four level cells that I believe are not yet on the market.
This is also nonsense. H1B workers are paid at least as well as their peers and cost significantly more due to legal and hr costs. The only valid criticism is that they are afraid to change jobs or rock the boat because they can be let go and then they must return to their home country. But right now talent is in such short supply that no one wants to upset a good worker. Big tech companies are drowning because they can't hire fast enough. Migrant laborers may create an underclass, not highly skilled h1b workers.
I am involved in hiring decisions at my company and at many companies prior to this one. I see what the applicants are. I see what the general talent pool is. I have several peers who are H1B and I can tell you they make very good money and I am absolutely not able to hire a similar citizen, otherwise I would simply hire both.
This AC is mostly nonsense in regards to the state of the industry. I agree about technical colleges though.
Companies would love to hire locally rather than H1B if there was talent. Blaming H1B is racist scapegoating. There are plenty of programmers out there. There aren't plenty of good programmers. If you learn the same web scripting language as everyone else and expect to make 6 figures right out of school you're in for a surprise. However, there are a LOT of companies who are hiring near 6 figures for talent immediately out of a 4 year program.
If you spend your 4 years writing only those programs assigned to you I'm sure it is difficult to find a good job. However, if you take an interest in opensource, do a good internship, or show any capability outside of filling in the last 1/10th of the program that your professor left blank for you, you'll have no trouble getting a job in today's market. What you get out of it is proportional to what you get in though. You can't just skate through and expect someone to hand you a pile of money. You're not entitled to anything just because you went through the motions and did what was laid out in front of you. You're competing with all of the other people who did the same, including those in other countries.
The crack at management is also unfounded. Everyone seems to know examples of mismanagement which lead to the failure of companies and the dissatisfaction and disenfranchisement of employees. Why then is it so hard to conceive that it is a difficult job that few people excel at? There are definitely good managers out there who can extract work from their reports at a higher level of satisfaction. You should learn to spot them and maneuver onto their teams at your earliest opportunity.
I'm a 10 year+ FreeBSD contributor. You're all missing the point. Linux and BSD target different markets and are optimized in all ways, organization, release process, license, code, to fit these different needs. One isn't better or worse. Obviously Linux is larger in all ways than BSD but larger doesn't mean better or we'd all just be using windows. This isn't a question of llvm being better than gcc, bsd being better than linux, or bsd license being better than gpl. They are just different and do different things. Use what's appropriate for your needs and leave it at that.
I can say as a long time contributor to opensource software I am disgusted at reading the comments of blowhard 'enthusiasts' who denigrate the hard work and contributions of hundreds of people when they get in these pissing matches. I am friend with Linux kernel contributors and I can guarantee we don't flame each other in this manner.
Erase blocks and data blocks are not the same size. The block size is the smallest atomic unit the operating system can write to. The erase block size is the smallest atomic unit the SSD can erase. Erase blocks typically contain hundreds of data blocks. They must be relatively larger so they can be electrically isolated. The SSD maintains a map from a linear block address space to a physical block addresses. The SSD may also maintain a map of which blocks within an erase block are valid and fills them as new writes come in.
Without TRIM, once written, the constituent blocks within an erase block are always considered valid. When one block in the erase block is overwritten, the whole thing must be RMW'd to a new place. With TRIM the drive controller can be smarter and only relocate those blocks that still maintain a valid mapping. This can drastically reduce the overhead on a well used drive.
I am incredibly offended that you would compare this bloated, brute-force, abomination of a chip to the incredibly well designed, elegant, and efficient Alpha (may it rest in peace).
"Like many things, there are always tradeoffs around, and if the goal is to play the "my file system has a longer d*ck" game, it's almost always possible to find some benchmark which "proves" that one file system is better than another. Yawn..."
Really Ted, where did I mention that softdep was better? This is a bit inappropriate. You seem keen on convincing everyone that softdep is so terrible for what reason I can't imagine. I'm not knocking your work. I've read your blog a bit, you're doing some great stuff. I'm just trying to clear up misconceptions.
There's a lot of misinformation in this thread about softupdates. I only have so much time to reply so I'll hit a few key points. I'm the author of journaling extensions to softupdates so I have some experience in this area.
This notion that softupdates was so complex and so inhibited new features in ffs is bogus. I've seen it repeated a few times. There simply was not much pressure for these features and the filesystem metadata did not support it until ufs2. The total amount of code dedicated to extended attributes in softupdates can't be more than 100 lines. ffs sees fewer features because we have fewer developers period.
Furthermore, softupdates is just a different approach. It is no more complex than journaling. When I review a sophisticated journaling implementation such as xfs I see more lines of code dedicated to journaling and transaction management than softupdates requires for dependency tracking. I have worked on a number of production filesystems and while softdep is definitely not trivial, neither were any of the others unless you compare to synchronous ufs. I think a lot of people who are familiar with COW and Journaling are looking at this unfairly because they already know another system and forget how long it took to become comfortable with it.
In cpu benchmarks softdep costs more than async ffs, this is true. However, rollbacks are actually quite infrequent because our buffercache attempts to write buffers without dependencies first. Generally there are enough of those which satisfy dependencies on other buffers that you can keep the pipeline busy. Looking at the code size and depth in any modern filesystem it's clear that a lot of cpu is involved. Are journal blocks not consuming memory? Is the transaction tracking free? Most dependency structures are quite small compared to generating a copy of a metadata block for a jouranl write.
NetBSD abandoned softdep for something much simpler because they didn't have the resources to fix the bugs in it and they didn't incorporate fixes from FreeBSD. Their journaling implementation is similar to our gjournal which is mostly filesystem agnostic and does full block logging in a very simple fashion.
The journaled filesystem project was started simply to get rid of fsck. I think this hybrid solution is very promising. It gives us a place to issue barriers which can affect arbitrary numbers of filesystem operations. The journal write overhead is much lower than with traditional journals.
And regarding benchmarks; FreeBSD doesn't really have a comparably developed journaling filesystem to benchmark softdep against. I think it's unreasonable to compare linux with ext4 to FreeBSD with ffs+softdep for purposes of evaluating the filesystem design. Too many other factors come into play.
You can read more about softdep journaling at http://jeffr_tech.livejournal.com/
You're talking to a group of people who mostly had regular access to internet pornography throughout their teenage years. I'd wager most managed to still become normal productive citizens. I bet a lot of them still did homework even. Not that I did, but it certainly wasn't due to porn. You can only wank for so many hours in a day, hormones or not.
Censoring kids just makes them sheltered and naive or criminals when they circumvent it.
To get condescending for a minute, you're full of it.
I've ridden campy centaur to record, and shimano sora to ultegra, zero gravity and ax lightness too. With rubber pads on alu rims each of these could lock a wheel. You can't come to a complete stop from high speeds because your center of gravity isn't low enough to keep you from flipping over not because your brakes aren't strong enough. If anything brakes tend to be weaker when they are cheaper because the arms flex more due to cheaper construction. Try to flex a pair of ZG or m5 arms, it's not going to happen.
The story is a little different with carbon rims. I find the brake pads designed for carbon vary significantly. I personally won't ride cork because sometimes rain happens. Coolstop pads I find last the longest but have the weakest stopping power. Swissstop may not be as durable but they stop almost as well as rubber on alu.
They don't make road race bikes with weak brakes to make the pack safer. That's a matter of good bike handling like holding your line. Track bikes do make the brakes weaker by removing them all together and forcing you to resist the motion of the pedals, which is possible because they are fixed gears with no freewheel.
You still don't know what you're talking about. That's not 30 bits of buffer, that's a 30bit window size. That's a 1 gigabyte buffer. Even if you had 128 gigabyte of ram, which I don't know how you've arrived at that, you probably don't want to use almost half of it for one transfer.
You don't seem to know what the problem or the solution is so I'm not sure how you know when it was solved by anyone including microsoft.
There are certainly many models other than strict flow control that can cope with packet loss but all of these also restrict bandwidth. Also, we were talking about TCP. The point being, you're going to have to do _something_ that will reduce your throughput from the theoretical maximum.
Even in your scheme the data must be available if the redundency protocol fails. Anyway, with these latencies you're really only going to do bulk file transfer so even normal tcp works with sack and a sufficiently large window if you can page your window in from disk. It certainly would be smart to build some redundancy in to the protocol but I wasn't exactly going for designing a martian transmission control protocol in a slashdot article where most people can't tell their asses from their elbows.;-)
Latency and bandwidth are not orthogonal when you have flow control. Try looking up 'bandwidth delay product' and tcp windowing. To achieve 1gbp/s to mars you need to buffer all that data in case of packet loss. Available memory will throttle your throughput.
A quick web search says round trip times to mars are between 10-50 minutes. Say 60 minutes * 60 seconds = 360 gigabits of window space to achieve full line rate. Now consider some minor packet loss and even with SACK you're buffering an unreasonable amount of data.
Annoying that the parent got modded up with bad information and this post will likely be passed over.
If you read the articles about this you will realize that the hardware is so cheap because they are anticipating sales of the service. They actually loose money when they sell the hardware w/o the service. So this company that uses some really neat technology (QNX) is going to go under if they keep selling cheap toys to linux geeks without selling their service. Think about that before you get terribly upset at them for forcing you to buy the service, or changing the machine so that it can't be moded. These people are struggling to make a buck just like the rest of us. Also I think we should be supportive of companies who are seeking alternatives to Microsoft products in light weight appliances. We need more companies like this to enhance competition so that we see more innovation.
I actually did a fair bit of digging into their protocol for authenticating cds. I didn't feel like figuring out their user auth code, so I just redirected the client's socket operations through some code I wrote to capture the stream and inject my own data where appropriate. I determined that it is completely impractical to fool their software. They request random sectors from the cd each time. Even on the same cd with different accounts. So even if I capture your session, playing it back won't buy me anything because the server will request different data. In order for this to be effective you have to have all data available, ie. the cd. Now if they only have a small subset of sectors that they check from each cd you could eventually find out what they are, but that would be much more hassle than it would be worth.
If you can sniff your neighbors traffic you could just get his email/password and login to his account. Or just sniff the mp3 streams and record them back to disk. The possibilities are really limitless there. Had the above method of recorded sessions worked people could have mailed out recorded sessions instead of trading mp3s.
-Jeff
PS. I did not do this with fraudulent intent. Record/Playback code is available upon request for those interested.
I have several questions which I will ask within the narrative below. The narrative is important to understand the context of the questions, and to support my arguments.
Several months ago I was raided by FBI for supposed involvement with the "hacker" group gh. The extent of my involvement was participating, as a caller only, in illegally funded phone conferences. JP, who also participated in this conferences, labeled me as a hacker, and a member of gh on his "news" site. Neither of these accusations are true. He has many more ties to this and other hacker groups than I have ever had. My first question is this; If you label me a hacker, than do you label yourself one? Are you in your little database of supposed computer criminals? Secondly, How can you pretend to be taking a stand against "hackers" while you are involved in the same activities?
My third question is in regards to your coverage of the situation. You posted unconfirmed information from an unreliable source in regards to the status of my employment at a prominent software development company. As a result of this I was contact by several news agencies, and immediately stereotyped as a hacker even though I have never illegally penetrated any computer system, nor had I been charged with, or accused of any crimes by the FBI. In response to this I granted one news agency an interview, which I thought went well, but also backfired. As a result of the negative press my former employer could not even consider allowing me to stay. My question being, Do you expect people to consider you as a reliable news source even though you report data which you receive through unreliable channels? And lastly, Did you ever stop to think what the impact of your coverage might be? It seems to me that in your rush for the big story you have failed to check for the correctness in your articles, and as a result of this you are hurting innocent people, such as myself. I'm sure this has gone on in other cases, but mine is the only one I have enough knowledge to comment on. I don't attribute these unfortunate events to you, but you certainly did not follow good news practices in reporting them. You have only served to injure my credibility and your own.
Lastly, have you ever considered what legal action may be taken against you for your involvement with these criminals? Do you even recognize the hypocrisy of your stance on hackers being one yourself by your own definition?
Slashdot Mirror
That makes logical sense but that is not how the terms are used in industry. MLC actually means two levels and TLC is three. QLC will be the term to describe four level cells that I believe are not yet on the market.
This is also nonsense. H1B workers are paid at least as well as their peers and cost significantly more due to legal and hr costs. The only valid criticism is that they are afraid to change jobs or rock the boat because they can be let go and then they must return to their home country. But right now talent is in such short supply that no one wants to upset a good worker. Big tech companies are drowning because they can't hire fast enough. Migrant laborers may create an underclass, not highly skilled h1b workers.
I am involved in hiring decisions at my company and at many companies prior to this one. I see what the applicants are. I see what the general talent pool is. I have several peers who are H1B and I can tell you they make very good money and I am absolutely not able to hire a similar citizen, otherwise I would simply hire both.
This AC is mostly nonsense in regards to the state of the industry. I agree about technical colleges though.
Companies would love to hire locally rather than H1B if there was talent. Blaming H1B is racist scapegoating. There are plenty of programmers out there. There aren't plenty of good programmers. If you learn the same web scripting language as everyone else and expect to make 6 figures right out of school you're in for a surprise. However, there are a LOT of companies who are hiring near 6 figures for talent immediately out of a 4 year program.
If you spend your 4 years writing only those programs assigned to you I'm sure it is difficult to find a good job. However, if you take an interest in opensource, do a good internship, or show any capability outside of filling in the last 1/10th of the program that your professor left blank for you, you'll have no trouble getting a job in today's market. What you get out of it is proportional to what you get in though. You can't just skate through and expect someone to hand you a pile of money. You're not entitled to anything just because you went through the motions and did what was laid out in front of you. You're competing with all of the other people who did the same, including those in other countries.
The crack at management is also unfounded. Everyone seems to know examples of mismanagement which lead to the failure of companies and the dissatisfaction and disenfranchisement of employees. Why then is it so hard to conceive that it is a difficult job that few people excel at? There are definitely good managers out there who can extract work from their reports at a higher level of satisfaction. You should learn to spot them and maneuver onto their teams at your earliest opportunity.
I'm a 10 year+ FreeBSD contributor. You're all missing the point. Linux and BSD target different markets and are optimized in all ways, organization, release process, license, code, to fit these different needs. One isn't better or worse. Obviously Linux is larger in all ways than BSD but larger doesn't mean better or we'd all just be using windows. This isn't a question of llvm being better than gcc, bsd being better than linux, or bsd license being better than gpl. They are just different and do different things. Use what's appropriate for your needs and leave it at that.
I can say as a long time contributor to opensource software I am disgusted at reading the comments of blowhard 'enthusiasts' who denigrate the hard work and contributions of hundreds of people when they get in these pissing matches. I am friend with Linux kernel contributors and I can guarantee we don't flame each other in this manner.
You're missing something.
Erase blocks and data blocks are not the same size. The block size is the smallest atomic unit the operating system can write to. The erase block size is the smallest atomic unit the SSD can erase. Erase blocks typically contain hundreds of data blocks. They must be relatively larger so they can be electrically isolated. The SSD maintains a map from a linear block address space to a physical block addresses. The SSD may also maintain a map of which blocks within an erase block are valid and fills them as new writes come in.
Without TRIM, once written, the constituent blocks within an erase block are always considered valid. When one block in the erase block is overwritten, the whole thing must be RMW'd to a new place. With TRIM the drive controller can be smarter and only relocate those blocks that still maintain a valid mapping. This can drastically reduce the overhead on a well used drive.
I am incredibly offended that you would compare this bloated, brute-force, abomination of a chip to the incredibly well designed, elegant, and efficient Alpha (may it rest in peace).
"Like many things, there are always tradeoffs around, and if the goal is to play the "my file system has a longer d*ck" game, it's almost always possible to find some benchmark which "proves" that one file system is better than another. Yawn..."
Really Ted, where did I mention that softdep was better? This is a bit inappropriate. You seem keen on convincing everyone that softdep is so terrible for what reason I can't imagine. I'm not knocking your work. I've read your blog a bit, you're doing some great stuff. I'm just trying to clear up misconceptions.
There's a lot of misinformation in this thread about softupdates. I only have so much time to reply so I'll hit a few key points. I'm the author of journaling extensions to softupdates so I have some experience in this area.
This notion that softupdates was so complex and so inhibited new features in ffs is bogus. I've seen it repeated a few times. There simply was not much pressure for these features and the filesystem metadata did not support it until ufs2. The total amount of code dedicated to extended attributes in softupdates can't be more than 100 lines. ffs sees fewer features because we have fewer developers period.
Furthermore, softupdates is just a different approach. It is no more complex than journaling. When I review a sophisticated journaling implementation such as xfs I see more lines of code dedicated to journaling and transaction management than softupdates requires for dependency tracking. I have worked on a number of production filesystems and while softdep is definitely not trivial, neither were any of the others unless you compare to synchronous ufs. I think a lot of people who are familiar with COW and Journaling are looking at this unfairly because they already know another system and forget how long it took to become comfortable with it.
In cpu benchmarks softdep costs more than async ffs, this is true. However, rollbacks are actually quite infrequent because our buffercache attempts to write buffers without dependencies first. Generally there are enough of those which satisfy dependencies on other buffers that you can keep the pipeline busy. Looking at the code size and depth in any modern filesystem it's clear that a lot of cpu is involved. Are journal blocks not consuming memory? Is the transaction tracking free? Most dependency structures are quite small compared to generating a copy of a metadata block for a jouranl write.
NetBSD abandoned softdep for something much simpler because they didn't have the resources to fix the bugs in it and they didn't incorporate fixes from FreeBSD. Their journaling implementation is similar to our gjournal which is mostly filesystem agnostic and does full block logging in a very simple fashion.
The journaled filesystem project was started simply to get rid of fsck. I think this hybrid solution is very promising. It gives us a place to issue barriers which can affect arbitrary numbers of filesystem operations. The journal write overhead is much lower than with traditional journals.
And regarding benchmarks; FreeBSD doesn't really have a comparably developed journaling filesystem to benchmark softdep against. I think it's unreasonable to compare linux with ext4 to FreeBSD with ffs+softdep for purposes of evaluating the filesystem design. Too many other factors come into play.
You can read more about softdep journaling at http://jeffr_tech.livejournal.com/
Thanks,
Jeff
You're talking to a group of people who mostly had regular access to internet pornography throughout their teenage years. I'd wager most managed to still become normal productive citizens. I bet a lot of them still did homework even. Not that I did, but it certainly wasn't due to porn. You can only wank for so many hours in a day, hormones or not.
Censoring kids just makes them sheltered and naive or criminals when they circumvent it.
There is a good interview with many key FreeBSD contributers about new technologies and improvements in 7.0. It is quite technical.
http://www.onlamp.com/pub/a/bsd/2008/02/26/whats-new-in-freebsd-70.html?page=1
$100 tires? How about $160 dugasts. ;-)
To get condescending for a minute, you're full of it.
I've ridden campy centaur to record, and shimano sora to ultegra, zero gravity and ax lightness too. With rubber pads on alu rims each of these could lock a wheel. You can't come to a complete stop from high speeds because your center of gravity isn't low enough to keep you from flipping over not because your brakes aren't strong enough. If anything brakes tend to be weaker when they are cheaper because the arms flex more due to cheaper construction. Try to flex a pair of ZG or m5 arms, it's not going to happen.
The story is a little different with carbon rims. I find the brake pads designed for carbon vary significantly. I personally won't ride cork because sometimes rain happens. Coolstop pads I find last the longest but have the weakest stopping power. Swissstop may not be as durable but they stop almost as well as rubber on alu.
They don't make road race bikes with weak brakes to make the pack safer. That's a matter of good bike handling like holding your line. Track bikes do make the brakes weaker by removing them all together and forcing you to resist the motion of the pedals, which is possible because they are fixed gears with no freewheel.
You still don't know what you're talking about. That's not 30 bits of buffer, that's a 30bit window size. That's a 1 gigabyte buffer. Even if you had 128 gigabyte of ram, which I don't know how you've arrived at that, you probably don't want to use almost half of it for one transfer.
You don't seem to know what the problem or the solution is so I'm not sure how you know when it was solved by anyone including microsoft.
There are certainly many models other than strict flow control that can cope with packet loss but all of these also restrict bandwidth. Also, we were talking about TCP. The point being, you're going to have to do _something_ that will reduce your throughput from the theoretical maximum.
;-)
Even in your scheme the data must be available if the redundency protocol fails. Anyway, with these latencies you're really only going to do bulk file transfer so even normal tcp works with sack and a sufficiently large window if you can page your window in from disk. It certainly would be smart to build some redundancy in to the protocol but I wasn't exactly going for designing a martian transmission control protocol in a slashdot article where most people can't tell their asses from their elbows.
Latency and bandwidth are not orthogonal when you have flow control. Try looking up 'bandwidth delay product' and tcp windowing. To achieve 1gbp/s to mars you need to buffer all that data in case of packet loss. Available memory will throttle your throughput.
A quick web search says round trip times to mars are between 10-50 minutes. Say 60 minutes * 60 seconds = 360 gigabits of window space to achieve full line rate. Now consider some minor packet loss and even with SACK you're buffering an unreasonable amount of data.
Annoying that the parent got modded up with bad information and this post will likely be passed over.
If you read the articles about this you will realize that the hardware is so cheap because they are anticipating sales of the service. They actually loose money when they sell the hardware w/o the service. So this company that uses some really neat technology (QNX) is going to go under if they keep selling cheap toys to linux geeks without selling their service.
Think about that before you get terribly upset at them for forcing you to buy the service, or changing the machine so that it can't be moded. These people are struggling to make a buck just like the rest of us. Also I think we should be supportive of companies who are seeking alternatives to Microsoft products in light weight appliances. We need more companies like this to enhance competition so that we see more innovation.
Jeff
I actually did a fair bit of digging into their protocol for authenticating cds. I didn't feel like figuring out their user auth code, so I just redirected the client's socket operations through some code I wrote to capture the stream and inject my own data where appropriate. I determined that it is completely impractical to fool their software. They request random sectors from the cd each time. Even on the same cd with different accounts. So even if I capture your session, playing it back won't buy me anything because the server will request different data. In order for this to be effective you have to have all data available, ie. the cd. Now if they only have a small subset of sectors that they check from each cd you could eventually find out what they are, but that would be much more hassle than it would be worth.
If you can sniff your neighbors traffic you could just get his email/password and login to his account. Or just sniff the mp3 streams and record them back to disk. The possibilities are really limitless there. Had the above method of recorded sessions worked people could have mailed out recorded sessions instead of trading mp3s.
-Jeff
PS. I did not do this with fraudulent intent. Record/Playback code is available upon request for those interested.
Several months ago I was raided by FBI for supposed involvement with the "hacker" group gh. The extent of my involvement was participating, as a caller only, in illegally funded phone conferences. JP, who also participated in this conferences, labeled me as a hacker, and a member of gh on his "news" site. Neither of these accusations are true. He has many more ties to this and other hacker groups than I have ever had. My first question is this; If you label me a hacker, than do you label yourself one? Are you in your little database of supposed computer criminals? Secondly, How can you pretend to be taking a stand against "hackers" while you are involved in the same activities?
My third question is in regards to your coverage of the situation. You posted unconfirmed information from an unreliable source in regards to the status of my employment at a prominent software development company. As a result of this I was contact by several news agencies, and immediately stereotyped as a hacker even though I have never illegally penetrated any computer system, nor had I been charged with, or accused of any crimes by the FBI. In response to this I granted one news agency an interview, which I thought went well, but also backfired. As a result of the negative press my former employer could not even consider allowing me to stay. My question being, Do you expect people to consider you as a reliable news source even though you report data which you receive through unreliable channels? And lastly, Did you ever stop to think what the impact of your coverage might be? It seems to me that in your rush for the big story you have failed to check for the correctness in your articles, and as a result of this you are hurting innocent people, such as myself. I'm sure this has gone on in other cases, but mine is the only one I have enough knowledge to comment on. I don't attribute these unfortunate events to you, but you certainly did not follow good news practices in reporting them. You have only served to injure my credibility and your own.
Lastly, have you ever considered what legal action may be taken against you for your involvement with these criminals? Do you even recognize the hypocrisy of your stance on hackers being one yourself by your own definition?
Sincerely,
Jeff