It's interesting that it's at the point where you probably have to actually have some experience working in the field to spot the 'cheats' going on compared to realtime. Things have come very far and it looks very impressive. The quality of the cheats have just gotten crazy over time.
No indirect lighting, no indirect lighting, no caustics, no hair/fur. Lot's of places where the lighting looks complex, but can be baked into the textures. Very carefully set to avoid those being noticable omissions/limitations.
All the shader work going on is pretty impressive.
The Unity demoes finally look to be even with the Unreal demoes.
Beyond pay, this also veers toward indentured servitude type stuff going on. Once here, the employer holds an unreasonable amount of power (firing means deportation). This is a very dangerous trend.
Not to say H1-B is always abused, I know some brilliant H1-B folks (company got H1-B to specifically get those people by name, and I get the impression they are paid a premium as well). But the trend of do some labor gymnastics to replace local with H1-B systematically... that's a problem.
The company cuts back jobs, and doesn't really 'hire' anyone. Instead they find a good old outsourcing firm to provide contract work cheaper than the people they laid off. At this point in the transaction, it's just good ol' American capitalist competition at work.
Now turn to the outsourcing company. They just landed a huge contract. But they don't have the manpower, so they need to hire new. They haven't laid anyone off. Now *they* can claim lack of available talent to apply for H1-Bs, and not have any layoffs to scrutinize. They can also at the time point to the work seeking pool and probably easily show they can't find the needed 150 applicants or whatever (because the near-future unemployed folks *still have jobs at that point in time*, so they don't count yet). So they get H1-Bs, staff up, get the staff trained, *then* there's a glut of 150 qualified American professionals on the market that, in theory, should make it difficult to justify H1-Bs in that area.
In theory, this should at least make companies like IBM and Wipro that do this thing be able to do so only sporadically in a given geographic area, but I don't think the process really scrutinizes the local area applicant pool as it should, so that facet of the surplus labor being not yet laid off is not so critical.
I understand the rational (also someone mentioned more efficient use of screen space as multiple windows share a single menu strip instead of repeating a usually identical menu in each window).
However, his statement was that he preferred the travel distance of the in-window menu strategy. You can't really respond to a preference with "you are wrong because of some design 'law' says you should like the other way".
Anytime someone calls 'law' in the highly subjective world of UI design, it frustrates me a tad. Maybe it can be a good guideline, but rarely does anything related to human behavior really deserve to rank as a 'law'.
No, because quantum computing has only a doubling of effectiveness against common symmetric algorithms. Quantum computing would be a bad day for RSA encryption and elliptic curve, but the symmetric ciphers are largely apathetic.
You can take any key you like, and then encrypt *that* using a smaller symmetric key, which would work nicely. Symmetric algorithms can use tiny keys and still be more secure than asymmetric, and are suitable for use in the context of protecting a key.
True, though if you let your machine pick the passhprase, in python: base64.b64encode(os.urandom(15))
You now have a 'passphrase' that would withstand billions of millenia of guessing by a system unbelievably beyond the fastest thing we can imagine today. Maybe you have to print that out to a few qr codes to remember, but oh well.
Yes, I've never seen a QR code have a problem scanning in from even pretty crappy photos.
However, I'd probably store the actual keys and encrypt them as usual, using the QR code to only store the key that decrypts the key (which can be 20 printable characters and still be damn near impossible to crack, requiring on average 20 billion millienia even if you could brute force a quadrillion guesses a second).
Actually, the leap day is quite different than daylight savings time.
Usually, February has 28 days, except when it has 29 days. This is like a leap second, where once in a great while, a minute has 61 seconds.
daylight savings time doesn't inject any new time, it just retreads old time/skips time.
Practically speaking, a leap second would have been easier to model like daylight savings time (repeat one of the 60 seconds usually found in a minute), except that would mean some portion of indicated time would be ambiguous. That would have been perhaps aggravating for a whole day (two '28ths' of february would be pretty ambiguous for real-world concerns), but for a second it seems a bit more trouble than it's worth for all time systems to understand that there can be 61 second minutes...
I think the only universal truth of enterprise software is software selected for someone based on executives having enjoyable golf games/trips. I see plenty of 'enterprise' stacks that are like you say, but also ones that are an unholy amalgamation of disjoint things from different companies.
Look at most sites that deploy javascript nowadays. The variable names are mangled beyond recognition, all whitespace and comments have been removed. It's already as difficult as debugging assembly code, but with limited upside. In theory at least, embracing a reality of bytecode rather than making an interpreted language behave like bytecode can get some gains.
the enterprise market. It only needs to work, not work well.
That's probably the most accurate succinct explanation of 'enterprise' software I've ever seen. Except the 'needs to work' part is generally a mild suggestion rather than a rule.
I'm just amused when people speak of 'enterprise grade' software as if typical enterprise software is something to actually look up to...
I think if you are willing to commit to being at least competitive with would-be upstarts, even if you still want to be profitable, the marketing momentum of being an established brand is potent stuff, even though the technical barriers to entry may be lower.
The problem is that Open Compute represents some wasted potential. When Open goes well, there is a large chunk of consensus around which good collaboration is done. For Open Compute, no two big players have really agreed on anything significant that wasn't otherwise a settled matter in the wider industry. The connector of a 'daughter' card is agreed upon, but there are at least 4 different conflicting mechanical specifications for what attaches to the connector. This is probably the closest to consensus new to Open compute. It's nice that they took up the slack where standards bodies have failed there, but generally it's chaotic and the suppliers are pretty abused in that ecosystem. It's a lot like what Wal Mart does to it's suppliers, but with a nice happy branding on it.
HDD company says HDDs are going to continue to be the best price/capacity for a while, and it's going to be awesome, traditional SSD company says that's bollocks and HDDs will be completely obviated in the same timeframe, and Intel/Micron say 'screw nand, we got something better'
It's great to see real advances in technology (unlike the various BS 'revolutions' that are commonplace in pure software), but it would be nice if once in a while a marketing person said something straightforward and honest.
If all roads end in microsoft, then MS is a little less put off by the community that won't touch VS.
MS wants to have a software development reality where you can't turn around without bumping into some potential reason to give money to MS. Previously, they hitched that all on the premise that a target market adopts Windows as the leverage point to get in. Now they are (seemingly) accepting that many market segments won't go that way (server and mobile particularly) and trying to tap into those markets.
I predict their efforts may bear fruit in mobile space, but I'm skeptical on the server space. I think most folks that would embrace MS server components would have already embraced Windows Server. As a key example, I have never met a shop that did SQL Server because they explicitly wanted it, but that it was the path of least resistance for supported database given an existing contract with MS.
The one caveat being that the APUs are probably still lacking in performance compared to the console APUs (that basically devoted most all of the power/cooling budget to the GPU and a very weak CPU). However a very modest discrete GPU would handily overcome that gap.
The cell processor was very briefly an interesting beast at the time it came out. It represented surprisingly good bang for the buck when the PS3 released. No console hardware before or since has been 'ahead of its time' enough to offset the inherent limitations of a home entertainment device.
Unfortunately, while it had tremendous capability to run certain traditional HPC jobs, it wasn't that good a match for what game developers needed most...
The current crop is particularly less compelling, since they were basically midrange PC at the time of launch.
I think HP and WebOS had bigger troubles than presumed threats from MS.
Palm couldn't get mindshare, only Apple can get people to buy into a single-vendor ecosystem these day. I loved WebOS, but there simply wasn't room in the market for any big third vendor (as Microsoft themselves can attest to).
Whatever chances WebOS had of getting a renewed push died the second Apotheker stepped in and started mutilating HP's standing consumer business, and particularly seemed to have utter contempt of any potential ambition. Mark Hurd seemed to be interested in pushing it and doing a significant effort around their consumer presence, but that was very far from his successors minds.
MS might have wanted to show scary things to their traditional partners, but I don't think HP's webOs even registered on their radar.
Slashdot Mirror
It's interesting that it's at the point where you probably have to actually have some experience working in the field to spot the 'cheats' going on compared to realtime. Things have come very far and it looks very impressive. The quality of the cheats have just gotten crazy over time.
No indirect lighting, no indirect lighting, no caustics, no hair/fur. Lot's of places where the lighting looks complex, but can be baked into the textures. Very carefully set to avoid those being noticable omissions/limitations.
All the shader work going on is pretty impressive.
The Unity demoes finally look to be even with the Unreal demoes.
Beyond pay, this also veers toward indentured servitude type stuff going on. Once here, the employer holds an unreasonable amount of power (firing means deportation). This is a very dangerous trend.
Not to say H1-B is always abused, I know some brilliant H1-B folks (company got H1-B to specifically get those people by name, and I get the impression they are paid a premium as well). But the trend of do some labor gymnastics to replace local with H1-B systematically... that's a problem.
The company cuts back jobs, and doesn't really 'hire' anyone. Instead they find a good old outsourcing firm to provide contract work cheaper than the people they laid off. At this point in the transaction, it's just good ol' American capitalist competition at work.
Now turn to the outsourcing company. They just landed a huge contract. But they don't have the manpower, so they need to hire new. They haven't laid anyone off. Now *they* can claim lack of available talent to apply for H1-Bs, and not have any layoffs to scrutinize. They can also at the time point to the work seeking pool and probably easily show they can't find the needed 150 applicants or whatever (because the near-future unemployed folks *still have jobs at that point in time*, so they don't count yet). So they get H1-Bs, staff up, get the staff trained, *then* there's a glut of 150 qualified American professionals on the market that, in theory, should make it difficult to justify H1-Bs in that area.
In theory, this should at least make companies like IBM and Wipro that do this thing be able to do so only sporadically in a given geographic area, but I don't think the process really scrutinizes the local area applicant pool as it should, so that facet of the surplus labor being not yet laid off is not so critical.
I understand the rational (also someone mentioned more efficient use of screen space as multiple windows share a single menu strip instead of repeating a usually identical menu in each window).
However, his statement was that he preferred the travel distance of the in-window menu strategy. You can't really respond to a preference with "you are wrong because of some design 'law' says you should like the other way".
Anytime someone calls 'law' in the highly subjective world of UI design, it frustrates me a tad. Maybe it can be a good guideline, but rarely does anything related to human behavior really deserve to rank as a 'law'.
No, because quantum computing has only a doubling of effectiveness against common symmetric algorithms. Quantum computing would be a bad day for RSA encryption and elliptic curve, but the symmetric ciphers are largely apathetic.
You can take any key you like, and then encrypt *that* using a smaller symmetric key, which would work nicely. Symmetric algorithms can use tiny keys and still be more secure than asymmetric, and are suitable for use in the context of protecting a key.
Yes, and you can encrypt a large key (e.g. RSA keys are big) with a symmetric algorithm.
True, though if you let your machine pick the passhprase, in python:
base64.b64encode(os.urandom(15))
You now have a 'passphrase' that would withstand billions of millenia of guessing by a system unbelievably beyond the fastest thing we can imagine today. Maybe you have to print that out to a few qr codes to remember, but oh well.
Yes, I've never seen a QR code have a problem scanning in from even pretty crappy photos.
However, I'd probably store the actual keys and encrypt them as usual, using the QR code to only store the key that decrypts the key (which can be 20 printable characters and still be damn near impossible to crack, requiring on average 20 billion millienia even if you could brute force a quadrillion guesses a second).
Actually, the leap day is quite different than daylight savings time.
Usually, February has 28 days, except when it has 29 days. This is like a leap second, where once in a great while, a minute has 61 seconds.
daylight savings time doesn't inject any new time, it just retreads old time/skips time.
Practically speaking, a leap second would have been easier to model like daylight savings time (repeat one of the 60 seconds usually found in a minute), except that would mean some portion of indicated time would be ambiguous. That would have been perhaps aggravating for a whole day (two '28ths' of february would be pretty ambiguous for real-world concerns), but for a second it seems a bit more trouble than it's worth for all time systems to understand that there can be 61 second minutes...
Keep in mind it's not unusual for a family of 4 to go out together.
I can personally wait the typically 4 months between theatrical release and home release, even for things I really care about.
Yeah, nice to see nothing I'd miss go away, and the annoying stuff go...
Well, someone probably could complain about auto-refresh, though I personally found it a silly waste of the servers' resources.
I think the only universal truth of enterprise software is software selected for someone based on executives having enjoyable golf games/trips. I see plenty of 'enterprise' stacks that are like you say, but also ones that are an unholy amalgamation of disjoint things from different companies.
Look at most sites that deploy javascript nowadays. The variable names are mangled beyond recognition, all whitespace and comments have been removed. It's already as difficult as debugging assembly code, but with limited upside. In theory at least, embracing a reality of bytecode rather than making an interpreted language behave like bytecode can get some gains.
the enterprise market. It only needs to work, not work well.
That's probably the most accurate succinct explanation of 'enterprise' software I've ever seen. Except the 'needs to work' part is generally a mild suggestion rather than a rule.
I'm just amused when people speak of 'enterprise grade' software as if typical enterprise software is something to actually look up to...
I think if you are willing to commit to being at least competitive with would-be upstarts, even if you still want to be profitable, the marketing momentum of being an established brand is potent stuff, even though the technical barriers to entry may be lower.
I would also consider that sentiment for the tech companies. Why *must* you have your tech company in SF area?
The problem is that Open Compute represents some wasted potential. When Open goes well, there is a large chunk of consensus around which good collaboration is done. For Open Compute, no two big players have really agreed on anything significant that wasn't otherwise a settled matter in the wider industry. The connector of a 'daughter' card is agreed upon, but there are at least 4 different conflicting mechanical specifications for what attaches to the connector. This is probably the closest to consensus new to Open compute. It's nice that they took up the slack where standards bodies have failed there, but generally it's chaotic and the suppliers are pretty abused in that ecosystem. It's a lot like what Wal Mart does to it's suppliers, but with a nice happy branding on it.
HDD company says HDDs are going to continue to be the best price/capacity for a while, and it's going to be awesome, traditional SSD company says that's bollocks and HDDs will be completely obviated in the same timeframe, and Intel/Micron say 'screw nand, we got something better'
It's great to see real advances in technology (unlike the various BS 'revolutions' that are commonplace in pure software), but it would be nice if once in a while a marketing person said something straightforward and honest.
If all roads end in microsoft, then MS is a little less put off by the community that won't touch VS.
MS wants to have a software development reality where you can't turn around without bumping into some potential reason to give money to MS. Previously, they hitched that all on the premise that a target market adopts Windows as the leverage point to get in. Now they are (seemingly) accepting that many market segments won't go that way (server and mobile particularly) and trying to tap into those markets.
I predict their efforts may bear fruit in mobile space, but I'm skeptical on the server space. I think most folks that would embrace MS server components would have already embraced Windows Server. As a key example, I have never met a shop that did SQL Server because they explicitly wanted it, but that it was the path of least resistance for supported database given an existing contract with MS.
The one caveat being that the APUs are probably still lacking in performance compared to the console APUs (that basically devoted most all of the power/cooling budget to the GPU and a very weak CPU). However a very modest discrete GPU would handily overcome that gap.
The cell processor was very briefly an interesting beast at the time it came out. It represented surprisingly good bang for the buck when the PS3 released. No console hardware before or since has been 'ahead of its time' enough to offset the inherent limitations of a home entertainment device.
Unfortunately, while it had tremendous capability to run certain traditional HPC jobs, it wasn't that good a match for what game developers needed most...
The current crop is particularly less compelling, since they were basically midrange PC at the time of launch.
Software developers assure me that CI and unit tests make software quality perfect, and bugs aren't possible anymore.
I think HP and WebOS had bigger troubles than presumed threats from MS.
Palm couldn't get mindshare, only Apple can get people to buy into a single-vendor ecosystem these day. I loved WebOS, but there simply wasn't room in the market for any big third vendor (as Microsoft themselves can attest to).
Whatever chances WebOS had of getting a renewed push died the second Apotheker stepped in and started mutilating HP's standing consumer business, and particularly seemed to have utter contempt of any potential ambition. Mark Hurd seemed to be interested in pushing it and doing a significant effort around their consumer presence, but that was very far from his successors minds.
MS might have wanted to show scary things to their traditional partners, but I don't think HP's webOs even registered on their radar.