Thankfully, most of the web that does not, isn't useful. Seriously, after adding necessary exceptions for a few days, the overwhelming majority of the web that I care about works just fine with NoScript installed. Most of what doesn't work is stupid, and the vanishingly small remainder is easy enough to whitelist with a click or two. Anything that requires clicking through whitelisting 37 domains to make it work properly, usually just turns out to be an adcrap laden hellhole that doesn't work at all even when it is 'working properly.'
Presumably because then, there won't be a backup available for the critical systems. There probably is some extensive backup infrastructure available, but you never activate it unless you genuinely *absolutely have to.* If something bad happens to the active systems while you have voluntarily taken down half your 911 infrastructure, "we didn't want to take down any convenience systems," really won't cut it as an excuse. Besides, the presumed backup probably isn't seamless, doesn't work quite as well, etc. You almost never have 100% capacity in your DR secondaries. They are usually just to tide you over in an emergency, and maintain some functionality.
If a solar system has only one thing in it and that thing is mostly just relatively undifferentiated hydrogen, that's going to be less interesting that a solar system with a bunch of things in it. (Regardless of any ideas about colonizing or anything else.) It's certainly still possible that there is something fascinating in that solar system, but at the moment, it would have to be something we still can't detect, so it's hard to get as excited about. Planets are fascinating things. They have interesting geology and interesting compositions. They also imply that there is enough mass for things smaller than planets, like comets and asteroids as well.
Will any e-lock company dare to guarantee that their e-lock for hotel room will be hack-proof?
Of course not. Nobody has ever guaranteed such a thing, except for shady dealing liars with the worst security of all. Anybody who works in security knows that any system which protects something sufficiently valuable, or is sufficiently widely deployed will eventually come up against some lock pick or safe cracker who has enough intelligence, free time, and interest. it's just a question of how long it takes to happen, and how inconvenient it is when he shows up. Adding such a guarantee would just be a giant banner attracting more interest from such people.
Besides, this isn't software. If the guarantee is disproven, and you have to push out patches, you can't just put them on an FTP server. you have to build physical hardware, ship it out, etc. It would be unreasonable to expect any company to do all of that for free. In some cases a company will do a free, voluntary recall out of pocket for the sake of good PR. But, it's hardly something you can demand.
While fully autonomous cars may be the more desirable future, computer backup systems like this are a more likely first step. Once people start getting used to cars making good decisions on the road, they will be more willing to give the computers even more control.
Yeah, I think it's obvious that in the long term, the way forward is to ban the option of human control on most roads. Human driving should be relegated to a novelty passtime on specially designated roads, scenic routes, and racing tracks. Any transportation infrastructure being build today should really be built with the assumption that it will eventually be used only by robotic vehicles at very high speeds. Given how far we have come in the past ten years with the technology, I fully expect that we could do a 100% switchover within twenty years if we gave a damn. But, as a society, we aren't really that forward looking, so nobody is currently talking about that in a serious way at this point. Consequently, 'transitional' technologies like the robotic crash preventer will be the only thing widely deployed in the near-medium term, and we'll still be talking about fully automated transportation as a futuristic idea twenty years from now.
But, they got easy access to shoot the "fun" stuff by making sure they only showed stuff where the criminals were acting like idiots. If Cops had made a habit of showing police brutality that actually made the cops look bad, they wouldn't have gotten permission to make the show any more. That fact influences the way the police are shown by the media. Even subtler things like who the cops are friends with effecting who hears about breaks in a popular case effect the way police are portrayed in the media. As much as violent cops are a sexy story, there is still a huge positive bias in coverage in favor of the police.
To be fair, Apple basically invented OpenCL. AMD has been trying to push OpenCL as a valid alternative to CUDA for programming GPU's, and thus APU's. Apple certainly focuses on consumer electronics these days, but they do still have a lot of "core technology" people working in less visible rolls, and doing some very real work.
Uhm. You are aware that using PHP for anything security related is like making a vault door out of lit sticks of dynamite, right?
There is nothing inherently dangerous about PHP. But, the phoChain login page is secured behind a normal HTTP / Apache login. So, we have it set up so you have to be logged in as a valid user before you can even see the phpChain login page. It's also on an internal server, so it can't be accessed from the Internet. (Or, if you can, we have far greater security concerns to take care of first!)
Lots of very large web sites use PHP in public facing applications every day. From what I understand, that includes Facebook. While it's easy to make vulnerabilities in PHP, there isn't any language where it is especially difficult to make them. In general, you introduce vulnerabilities in proportion to the amoung of pieces that are in motion. Something like phpChain really only does a few small things, so it is easy to see how every feature interacts with every other feature. Compared to something like Wordpress, something like phpChain is much easier to get right. It doesn't need to give content to untrusted users. It doesn't need to interoperate with other sites. It doesn't need feeds or pingbacks. It doesn't support public comments. It doesn't do embedded flash. It doesn't need a full SQL backend. It just stores some passwords. And, it does it well.
We just use a shared account for "engineering department (location XYZ)" passwords. You can also have an individual account if you want to have private passwords, and you could put the password for any shared phpChain accounts you need to access in your private phpChain account. We have it running on an internal server, rather then something exposed to the Internet, so the danger of a breach is minimal. (If anybody makes it that far, we are already hosed.) But, the passwords are all stored in an encrypted form, so we could safely send backups offsite if we needed to, etc. Also, you need to log into the page with a normal HTTP login (which is tied to the NIS account you use everywhere on our network) before you log in with the shared phpChain account, so we have an audit trail wrt which individual person accessed what, despite using shared accounts.
We use phpchain at work for this sort of thing. A few hundred accounts for various servers, devices, vendor support accounts, and logins for accounts at companies we work with. All stored securely. Google it if you arent familiar with it. It has been a huge win for us, and does everything asked for. We even wrote a simple search functionality for at that I think has been rolled into mainlIne at this point. Certainly better than a plain text file on a shared drive!
(tried posting this previously, but I wasn't logged in. Trying again now that I have gotten home. Hopefully it is more noticeable now.)
Okay, sure, OpenCV is terrible. But, what do you reccomend as the alternative? I think it's similar to ffmpeg in a lot of ways. Sure, the API has grown like a cancer, but as inelegant as it may be, what else has the same functionality and reasonable licensing terms that you can use to pull off the shelf and start hacking? Complain about the speed if you want, but if I use OpenCV, it certainly runs better than if I had to try to reimplement all the code myself! IMHO, part of the problem is scope creep. OpenCV includes stuff like file IO and GUI development. If they just gave up on that, and kept easy interoperability with OIIO and Qt, and focused on only maintaining actual computer vision code, the scope might be more manageable. (And, focusing on documentation so I could have half a chance at actually using the mess woulkdn''t hurt either...)
I'm skeptical of the cost. $60B 2010 dollars is the estimated cost for high speed rail from SF and Sacramento to LA and San Diego. You're telling me I can get a maglev to fucking space for that much? Please do it if it's true, but I don't believe it.
Fair point, but when you look at how much cheaper-per-mile the LA-San Diego line will be compared to the LA expo line expansion, it's clear that these things scale very non-linearly, and cost more when you have to deal with existing infrastructure and population. Stick a megastructure in the middle of some accessible but vacant desert, and you will get a lot more bang for the buck than if you tried to stick it near extremely desirable California coastline.
Maybe not. Even in the 90s the CGI resolution probably exceeded 1080p. The low res may have been introduced in the conversion to TV. Or are you really referring to low triangle counts and primitive shading compared to today's norms?
I'm sorry, but this is not correct. Absolutely nobody in that period was working on TV CG at greater than 1080p. The exact resolution would depend on what exactly they were using, and AFAIK, I don't know anybody who worked on TNG to ask about workflow details. But, I do work with somebody who worked on early Flame and a lot of people who were Lightwave artists during the B5/SeaQuest days. It was all done in SD at the time.
Remember, TNG started in the 80's and ended in 1994. During the TNG era, PC's ran DOS. Irix based Flame workstations cost most of a million dollars and had less power than an old iPhone. Amigas were the kings of TV effects. Nobody had the memory or storage to keep rendered HD frames around for no reason. There was no way to broadcast that resolution, no medium to sell it on. Nobody had displays that would show 1080p. At that point, Lightwave had a serial port tape deck control feature so that you could render frame-by-frame directly to video tape under the assumption that you didn't even have the storage space for your few seconds of 640x480 SD. Even the film guys, with much bigger budgets than TV, were a long way from having the available storage to do things like a full Digital Intermediate. (It didn't happen until O Brother Where Art Thou.) As late as 2000, a lot of film projects were doing VFX at less than 1080p resolution, even without trying to do a full DI.
Certainly, in additional to all that the geometry was less detailed than it would be today, and shading and compositing was simpler. It was still amazing for the time, and I'd love to see a "cleanup only" version of TNG which didn't try to add new CG effects. At this point, it really just has to be appreciated as a product of the time in which it was made, rather than trying to recapture the sense of awe you remember from watching it all those years ago by (mis)using modern CGI.
Actual link latency doesn't effect throughput, while all the time spent going from optics->CPU->optics does. If you could build an all optical router, it would be theoretically capable of very good results. Also, fiber is frequently used for much shorter hops as well. We have hundreds of optical links at the place where I work, and that's all inside a very small room. If more of the infrastructure was 100% optical, that could improve things a lot over the next few years.
A Dongle is a major PITA if you have multiple seats and floating licenses and such. The Autodesk license server does suck, but it is no worse than most similar solutions. We use Flames and Maya, and they need separate instances of the license server. Whenever we get new software, it always takes a week of calls with Autodesk to get the proper license issued after a couple of false starts that miss some of our tokens.
I do wish somebody would make an open source license manager that could become the "standard" server in some cryptographically secure way. Offer a Java plugin API for vendors to supply modules to run confidence checks on the server, but have the actual server itself just be a normal package in the RHEL/Ubuntu/Ports repository that you can install directly in the OS vendor supported configuration. Drop license tokens and confidence check plugins into well specified directories. It would be so much better for everybody, both users and vendors. It could reduce floating licenses to a question equivalent to, "Which protocol should I use for serving HTML pages over the internet? HTTP, or roll my own?"
I have 8gb of memory on my main computer. I want firefox to use up as much of it as it can to improve my browsing experience.
I have 16 GB on my main system, and I don't want Firefox sucking up all my RAM. Firefox devs seem to miss a few key points about what I think is a very common usage model: A - Browsing is not my primary Application. (For me, it's graphics software. Other people may have MS Office or an IDE.) B - Browsing is the one app where I never want to lose state. (I'm willing to close my compositing app from time to time to free up resources for other things because it is my "Primary" action. I'm either doing it or I'm not. I can close it down between sessions and open the one document I was working on when I get back to it. The Browser should be "always there," because it has stuff like my gmail, and I want to see new mail come in. It also has dozens of tabs of unfinished reading because, again, browsing isn't my primary activity so whenever something comes up, I leave it quickly and come back to it in downtime.) C - I will have multiple browsers open at any given time. (On Windows, I may need IE for an intranet thing. For me, I usually have FF + Chrome so I can be signed into work and personal google accounts at the same time. So,w ahetever RAM is a reasonable allocation for browsing, Firefox should take less than a third of that.)
So, even if browsing would be slightly improved by filling up tens of GB's of RAM with cached nonesense, I never actually want that to go to Firefox. I want Firefox to stay as conservative as possible so that I can comfortably leave my dozens of tabs open while I usu an app that's actually important, and then come back to them without losing the "mental state" of what I was reading on IMDB and wikipedia and my google searches about potions to make somebody fall in love with me, or whatever the hell I was doing.
His point is reasonable, though probably a bit subtle for many audiences. "Access to communication" might well be a human right, but we shouldn't add "the Internet" to a special list for the same reason that we can be glad our predecessors didn't add "telegraph service" to the list.
I agree that his point is reasonable. If there is a human right related to the Internet, I would say that it is the right to create your own networks, whether social or digital. The ability to exchange information freely with your peers is both something I think of as a human right, and also a fundamental design feature of the Internet. So, while Internet access clearly isn't a human right, I think that's not to say that the Internet doesn't deserve a mention in a discussion about how human rights are exercised in the modern world.
There is no no-compete or non-disclosure in my file. There is no "domain rule" blanketing what I do outside of my job scope. The skills were not attained at this current employer but instead were amassed on my own time out of sheer hobby. The fact they were not divulged at the time of interview and hire are irrelevant.
"The skills were not attained at this current employer," may not be relevant if they go that route. You wrote it in response to knowledge about their processes and systems and such. Therefore, your on the clock time was "market research" for your product. If they want to be that kind of a dick, they can be that kind of a dick. Thankfully though if that was especially likely at your workplace, you would probably already smell it, and would already have given up.
That said, I'm not optimistic. I have had basically the same idea at a few points, and it never really seemed like a good idea. If I write something on my own time, and sell it as "boxed" commercial software to my current employer then I'm also the only tech support person. If there is a problem with the software, I'm not going to refuse to think about it until I get off work, so maintaining the "wall of separation" is basically impossible in reality. Maintaining it makes me the worst possible software vendor because I can never be available during my only client's business hours. If I don't maintain the wall of separation, then the project effectively becomes an on-the-job thing. If it is brought up as an on the job thing, they will see the project as just part of my job, and won't be excited about paying me for it. They'll see me as trying to blackmail them for access to something which I'm now saying is part of my job.
There's no guarantee it'll end badly, but it's absolutely a possibility. And remember, just because it doesn't go bad in the first week doesn't mean that some asshat new manager won't come along at some point in the future and misunderstand the situation and make a mess of things for you. So, whenever I have written this sort of software, I always just use company resources and give it to the company, and consider it my job from the start. It keeps things simple for me. It keeps employers happy. Coworkers tend to like having me around as they guy who probably has some way to fix their problems.
I'm not saying you shouldn't ask if it already exists, but I am suggesting you be mindful of the long road. It can be bumpy. If you want to earn some scratch developing on the side, I'd suggest keeping it completely separated from your day job in every way. Write games. Write recipe databases. Write raytracers. Just write anything that you have no use for at work.
And that fact that it was referred to as C1X during development is the reason that many people still recognize the name, and it is thus "known unofficially as C1X." The statements you quoted aren't in any sense mutually exclusive.
Re:Anyone else do an easy Domains by Proxy?
on
GoDaddy Backs SOPA
·
· Score: 1
I used godaddy solely because they also offered Domains by Proxy, allowing me to keep my real identity secret. I don't use them for hosting though.
I use dreamhost, and my domain whois info is all under "Dreamhost Customer." I have the option to fill it in, but have never bothered, so I seem to get this "special privacy proxy service" just by default. This is what happened with getting the domain as part of my hosting plan. Not sure if they similarly proxy for people who bring their own domains, but it is certainly worth asking. Several other slashdotters appear to be using their services as well, so it is a reasonably well respected hosting company. (I like my ssh access and mySQL access and such. I barely even use it as a 'real' website. Quite slashdotter friendly, IMO.) I suspect it would be similar with other providers. Of course, my domain name is just my real name, so I obviously wasn't terribly careful about keeping that a secret, but I think the principle obviously applies with more clever domain names:
Registrant Contact:
willrosecrans.com Private Registrant willrosecrans.com@proxy.dreamhost.com
A Happy DreamHost Customer
417 Associated Rd #324
Brea, CA 92821
US
+1.2139471032
Administrative Contact:
willrosecrans.com Private Registrant willrosecrans.com@proxy.dreamhost.com
A Happy DreamHost Customer
417 Associated Rd #324
Brea, CA 92821
US
+1.2139471032
Technical Contact:
willrosecrans.com Private Registrant willrosecrans.com@proxy.dreamhost.com
A Happy DreamHost Customer
417 Associated Rd #324
Brea, CA 92821
US
+1.2139471032
Billing Contact:
willrosecrans.com Private Registrant willrosecrans.com@proxy.dreamhost.com
A Happy DreamHost Customer
417 Associated Rd #324
Brea, CA 92821
US
+1.2139471032
No, it was when two different softwares were used to calculate thrust. The spacecraft software calculated thrust correctly in newton-seconds. The ground software calculated thrust in pounds force-seconds. This was contrary to the software interface specification, which called out newton-seconds. The result was that the ground-calculated trajectory was more than 20 kilometers too close to the surface. The engineers didn't "forget to convert", they failed to read and understand the specifications.
To be fair, it wan't like they were just outputting the wrong units. They were outputting the right units, per the spec. They were just using a different set of units for the internal calculation, and then got bit by precision problems in the conversion. Basically, it was a rounding error. Theoretically, the details of the math could be fairly arbitrary as a "black box API." They just needed an infinite number of bits and it would have worked fine...
In 2002, Outlook Express offered integrated s/mime encryption + digital signatures. Once you installed your certificate (which, was simply double clicking a.p12 file, and entering your import password), you could encrypt or sign email going out, with a single click. It verified signatures in inbound email too, all in an integrated UI.
Unfortunately, even that's not easy enough for my mom. Nowehere near easy enough, in fact. In order to popularise encrypted email, you have to surrender the idea of out of band key exchange and the concept of web of trust. You also need a highly interoparable way to have it just magically work by default. One good starting place would be a "Public Key At URL" header standard in all email. If you had that, you can imagine a future scenario circa 2015...
Ordinary corporate email user alice@example.com fires up Outlook 2014. A key has been automatically generated for the user without them knowing it on the Exchange server. Alice sends an ordinary unsecured email to bob@othercorp.com without pushing any extra buttons. This is the first time they have corresponded. Alice's email client includes a header for public-key-location which states that her public key is stored at "https://exchange.example.com/keys/alice". Bob doesn't specifically check email headers, so he just sees a normal email in his inbox. He decides to reply. His email client sees that he is sending to an email address with a known public key location, so it downloads alice's key automatically, and uses it to encrypt bob's message to alice so that only she can read it. This fact manifests itself as a discreet "encrypt" checkbox in the compose email window of bob's mail client. He never needs to manually intervene in the process unless he wants to install a key manually, or actively turn off encryption. Most people would never specifically do that.
The technology for that kind of infrastructure has been in place for ages. But, there isn't a critical mass that want's it. The security die hards want a system with manual key verification, and user awareness and training. Microsoft might create something similar to what I describe, but it would only work with Outlook and be explicitly incompatible with anything that isn't an Exchange client. And, they would do all decryption server side with decrypted mail stores so IT can audit corporate email. The overwhelming majority of users just don't care. But, basically one of the big players (Microsoft? Google?) needs to create a whole ecosystem in one swoop, with a massive installed base automatically, in order to get any real traction.
And the rest of us tend to put anything important through a medium other than email. scp for files, ssh tunnels for random things, ssh and talk for nefarious conversations.
On some tv commercials you'll see "Screen images simulated, sequences shortened." So what you're seeing is fantasy compared to how the phone actually works. Its a bit much.
In some cases, advertisements are worked on before software even exists in a final form, so it would be impossible to actually use on set. As a result, you get a motion graphics artist doing their best to convey the impression of the UI, but it's not perfect. Even when the software does exist, shooting an actual phone screen with a camera usually results in something very difficult to see, and completely unlike what you experience with your own eyes. So, you shoot with a turned off phone with an actor vaguely pecking at imaginary buttons. When the UI gets comped in, the buttons have to be wherever the actor was poking at. If you used screenshots that look exactly like the actual software, it would be responding in impossible ways at the actor poked where the send an email button goes, but then starts talking into the phone like he is on a call.
So, the best option winds up being a bit impressionistic. It's not perfect, but nothing is.
Slashdot Mirror
Thankfully, most of the web that does not, isn't useful. Seriously, after adding necessary exceptions for a few days, the overwhelming majority of the web that I care about works just fine with NoScript installed. Most of what doesn't work is stupid, and the vanishingly small remainder is easy enough to whitelist with a click or two. Anything that requires clicking through whitelisting 37 domains to make it work properly, usually just turns out to be an adcrap laden hellhole that doesn't work at all even when it is 'working properly.'
Presumably because then, there won't be a backup available for the critical systems. There probably is some extensive backup infrastructure available, but you never activate it unless you genuinely *absolutely have to.* If something bad happens to the active systems while you have voluntarily taken down half your 911 infrastructure, "we didn't want to take down any convenience systems," really won't cut it as an excuse. Besides, the presumed backup probably isn't seamless, doesn't work quite as well, etc. You almost never have 100% capacity in your DR secondaries. They are usually just to tide you over in an emergency, and maintain some functionality.
If a solar system has only one thing in it and that thing is mostly just relatively undifferentiated hydrogen, that's going to be less interesting that a solar system with a bunch of things in it. (Regardless of any ideas about colonizing or anything else.) It's certainly still possible that there is something fascinating in that solar system, but at the moment, it would have to be something we still can't detect, so it's hard to get as excited about. Planets are fascinating things. They have interesting geology and interesting compositions. They also imply that there is enough mass for things smaller than planets, like comets and asteroids as well.
Of course not. Nobody has ever guaranteed such a thing, except for shady dealing liars with the worst security of all. Anybody who works in security knows that any system which protects something sufficiently valuable, or is sufficiently widely deployed will eventually come up against some lock pick or safe cracker who has enough intelligence, free time, and interest. it's just a question of how long it takes to happen, and how inconvenient it is when he shows up. Adding such a guarantee would just be a giant banner attracting more interest from such people.
Besides, this isn't software. If the guarantee is disproven, and you have to push out patches, you can't just put them on an FTP server. you have to build physical hardware, ship it out, etc. It would be unreasonable to expect any company to do all of that for free. In some cases a company will do a free, voluntary recall out of pocket for the sake of good PR. But, it's hardly something you can demand.
Yeah, I think it's obvious that in the long term, the way forward is to ban the option of human control on most roads. Human driving should be relegated to a novelty passtime on specially designated roads, scenic routes, and racing tracks. Any transportation infrastructure being build today should really be built with the assumption that it will eventually be used only by robotic vehicles at very high speeds. Given how far we have come in the past ten years with the technology, I fully expect that we could do a 100% switchover within twenty years if we gave a damn. But, as a society, we aren't really that forward looking, so nobody is currently talking about that in a serious way at this point. Consequently, 'transitional' technologies like the robotic crash preventer will be the only thing widely deployed in the near-medium term, and we'll still be talking about fully automated transportation as a futuristic idea twenty years from now.
"For Workgroups" is now called "The Cloud."
But, they got easy access to shoot the "fun" stuff by making sure they only showed stuff where the criminals were acting like idiots. If Cops had made a habit of showing police brutality that actually made the cops look bad, they wouldn't have gotten permission to make the show any more. That fact influences the way the police are shown by the media. Even subtler things like who the cops are friends with effecting who hears about breaks in a popular case effect the way police are portrayed in the media. As much as violent cops are a sexy story, there is still a huge positive bias in coverage in favor of the police.
To be fair, Apple basically invented OpenCL. AMD has been trying to push OpenCL as a valid alternative to CUDA for programming GPU's, and thus APU's. Apple certainly focuses on consumer electronics these days, but they do still have a lot of "core technology" people working in less visible rolls, and doing some very real work.
At that point, nobody had ever lost a remote control, so it would have been a fairly unappealing selling point for a lot of people.
There is nothing inherently dangerous about PHP. But, the phoChain login page is secured behind a normal HTTP / Apache login. So, we have it set up so you have to be logged in as a valid user before you can even see the phpChain login page. It's also on an internal server, so it can't be accessed from the Internet. (Or, if you can, we have far greater security concerns to take care of first!)
Lots of very large web sites use PHP in public facing applications every day. From what I understand, that includes Facebook. While it's easy to make vulnerabilities in PHP, there isn't any language where it is especially difficult to make them. In general, you introduce vulnerabilities in proportion to the amoung of pieces that are in motion. Something like phpChain really only does a few small things, so it is easy to see how every feature interacts with every other feature. Compared to something like Wordpress, something like phpChain is much easier to get right. It doesn't need to give content to untrusted users. It doesn't need to interoperate with other sites. It doesn't need feeds or pingbacks. It doesn't support public comments. It doesn't do embedded flash. It doesn't need a full SQL backend. It just stores some passwords. And, it does it well.
We just use a shared account for "engineering department (location XYZ)" passwords. You can also have an individual account if you want to have private passwords, and you could put the password for any shared phpChain accounts you need to access in your private phpChain account. We have it running on an internal server, rather then something exposed to the Internet, so the danger of a breach is minimal. (If anybody makes it that far, we are already hosed.) But, the passwords are all stored in an encrypted form, so we could safely send backups offsite if we needed to, etc. Also, you need to log into the page with a normal HTTP login (which is tied to the NIS account you use everywhere on our network) before you log in with the shared phpChain account, so we have an audit trail wrt which individual person accessed what, despite using shared accounts.
We use phpchain at work for this sort of thing. A few hundred accounts for various servers, devices, vendor support accounts, and logins for accounts at companies we work with. All stored securely. Google it if you arent familiar with it. It has been a huge win for us, and does everything asked for. We even wrote a simple search functionality for at that I think has been rolled into mainlIne at this point. Certainly better than a plain text file on a shared drive!
(tried posting this previously, but I wasn't logged in. Trying again now that I have gotten home. Hopefully it is more noticeable now.)
Okay, sure, OpenCV is terrible. But, what do you reccomend as the alternative? I think it's similar to ffmpeg in a lot of ways. Sure, the API has grown like a cancer, but as inelegant as it may be, what else has the same functionality and reasonable licensing terms that you can use to pull off the shelf and start hacking? Complain about the speed if you want, but if I use OpenCV, it certainly runs better than if I had to try to reimplement all the code myself! IMHO, part of the problem is scope creep. OpenCV includes stuff like file IO and GUI development. If they just gave up on that, and kept easy interoperability with OIIO and Qt, and focused on only maintaining actual computer vision code, the scope might be more manageable. (And, focusing on documentation so I could have half a chance at actually using the mess woulkdn''t hurt either...)
Fair point, but when you look at how much cheaper-per-mile the LA-San Diego line will be compared to the LA expo line expansion, it's clear that these things scale very non-linearly, and cost more when you have to deal with existing infrastructure and population. Stick a megastructure in the middle of some accessible but vacant desert, and you will get a lot more bang for the buck than if you tried to stick it near extremely desirable California coastline.
I'm sorry, but this is not correct. Absolutely nobody in that period was working on TV CG at greater than 1080p. The exact resolution would depend on what exactly they were using, and AFAIK, I don't know anybody who worked on TNG to ask about workflow details. But, I do work with somebody who worked on early Flame and a lot of people who were Lightwave artists during the B5/SeaQuest days. It was all done in SD at the time.
Remember, TNG started in the 80's and ended in 1994. During the TNG era, PC's ran DOS. Irix based Flame workstations cost most of a million dollars and had less power than an old iPhone. Amigas were the kings of TV effects. Nobody had the memory or storage to keep rendered HD frames around for no reason. There was no way to broadcast that resolution, no medium to sell it on. Nobody had displays that would show 1080p. At that point, Lightwave had a serial port tape deck control feature so that you could render frame-by-frame directly to video tape under the assumption that you didn't even have the storage space for your few seconds of 640x480 SD. Even the film guys, with much bigger budgets than TV, were a long way from having the available storage to do things like a full Digital Intermediate. (It didn't happen until O Brother Where Art Thou.) As late as 2000, a lot of film projects were doing VFX at less than 1080p resolution, even without trying to do a full DI.
Certainly, in additional to all that the geometry was less detailed than it would be today, and shading and compositing was simpler. It was still amazing for the time, and I'd love to see a "cleanup only" version of TNG which didn't try to add new CG effects. At this point, it really just has to be appreciated as a product of the time in which it was made, rather than trying to recapture the sense of awe you remember from watching it all those years ago by (mis)using modern CGI.
Actual link latency doesn't effect throughput, while all the time spent going from optics->CPU->optics does. If you could build an all optical router, it would be theoretically capable of very good results. Also, fiber is frequently used for much shorter hops as well. We have hundreds of optical links at the place where I work, and that's all inside a very small room. If more of the infrastructure was 100% optical, that could improve things a lot over the next few years.
A Dongle is a major PITA if you have multiple seats and floating licenses and such. The Autodesk license server does suck, but it is no worse than most similar solutions. We use Flames and Maya, and they need separate instances of the license server. Whenever we get new software, it always takes a week of calls with Autodesk to get the proper license issued after a couple of false starts that miss some of our tokens.
I do wish somebody would make an open source license manager that could become the "standard" server in some cryptographically secure way. Offer a Java plugin API for vendors to supply modules to run confidence checks on the server, but have the actual server itself just be a normal package in the RHEL/Ubuntu/Ports repository that you can install directly in the OS vendor supported configuration. Drop license tokens and confidence check plugins into well specified directories. It would be so much better for everybody, both users and vendors. It could reduce floating licenses to a question equivalent to, "Which protocol should I use for serving HTML pages over the internet? HTTP, or roll my own?"
I have 16 GB on my main system, and I don't want Firefox sucking up all my RAM. Firefox devs seem to miss a few key points about what I think is a very common usage model: A - Browsing is not my primary Application. (For me, it's graphics software. Other people may have MS Office or an IDE.) B - Browsing is the one app where I never want to lose state. (I'm willing to close my compositing app from time to time to free up resources for other things because it is my "Primary" action. I'm either doing it or I'm not. I can close it down between sessions and open the one document I was working on when I get back to it. The Browser should be "always there," because it has stuff like my gmail, and I want to see new mail come in. It also has dozens of tabs of unfinished reading because, again, browsing isn't my primary activity so whenever something comes up, I leave it quickly and come back to it in downtime.) C - I will have multiple browsers open at any given time. (On Windows, I may need IE for an intranet thing. For me, I usually have FF + Chrome so I can be signed into work and personal google accounts at the same time. So,w ahetever RAM is a reasonable allocation for browsing, Firefox should take less than a third of that.)
So, even if browsing would be slightly improved by filling up tens of GB's of RAM with cached nonesense, I never actually want that to go to Firefox. I want Firefox to stay as conservative as possible so that I can comfortably leave my dozens of tabs open while I usu an app that's actually important, and then come back to them without losing the "mental state" of what I was reading on IMDB and wikipedia and my google searches about potions to make somebody fall in love with me, or whatever the hell I was doing.
I agree that his point is reasonable. If there is a human right related to the Internet, I would say that it is the right to create your own networks, whether social or digital. The ability to exchange information freely with your peers is both something I think of as a human right, and also a fundamental design feature of the Internet. So, while Internet access clearly isn't a human right, I think that's not to say that the Internet doesn't deserve a mention in a discussion about how human rights are exercised in the modern world.
"The skills were not attained at this current employer," may not be relevant if they go that route. You wrote it in response to knowledge about their processes and systems and such. Therefore, your on the clock time was "market research" for your product. If they want to be that kind of a dick, they can be that kind of a dick. Thankfully though if that was especially likely at your workplace, you would probably already smell it, and would already have given up.
That said, I'm not optimistic. I have had basically the same idea at a few points, and it never really seemed like a good idea. If I write something on my own time, and sell it as "boxed" commercial software to my current employer then I'm also the only tech support person. If there is a problem with the software, I'm not going to refuse to think about it until I get off work, so maintaining the "wall of separation" is basically impossible in reality. Maintaining it makes me the worst possible software vendor because I can never be available during my only client's business hours. If I don't maintain the wall of separation, then the project effectively becomes an on-the-job thing. If it is brought up as an on the job thing, they will see the project as just part of my job, and won't be excited about paying me for it. They'll see me as trying to blackmail them for access to something which I'm now saying is part of my job.
There's no guarantee it'll end badly, but it's absolutely a possibility. And remember, just because it doesn't go bad in the first week doesn't mean that some asshat new manager won't come along at some point in the future and misunderstand the situation and make a mess of things for you. So, whenever I have written this sort of software, I always just use company resources and give it to the company, and consider it my job from the start. It keeps things simple for me. It keeps employers happy. Coworkers tend to like having me around as they guy who probably has some way to fix their problems.
I'm not saying you shouldn't ask if it already exists, but I am suggesting you be mindful of the long road. It can be bumpy. If you want to earn some scratch developing on the side, I'd suggest keeping it completely separated from your day job in every way. Write games. Write recipe databases. Write raytracers. Just write anything that you have no use for at work.
And that fact that it was referred to as C1X during development is the reason that many people still recognize the name, and it is thus "known unofficially as C1X." The statements you quoted aren't in any sense mutually exclusive.
I use dreamhost, and my domain whois info is all under "Dreamhost Customer." I have the option to fill it in, but have never bothered, so I seem to get this "special privacy proxy service" just by default. This is what happened with getting the domain as part of my hosting plan. Not sure if they similarly proxy for people who bring their own domains, but it is certainly worth asking. Several other slashdotters appear to be using their services as well, so it is a reasonably well respected hosting company. (I like my ssh access and mySQL access and such. I barely even use it as a 'real' website. Quite slashdotter friendly, IMO.) I suspect it would be similar with other providers. Of course, my domain name is just my real name, so I obviously wasn't terribly careful about keeping that a secret, but I think the principle obviously applies with more clever domain names:
Registrant Contact:
willrosecrans.com Private Registrant willrosecrans.com@proxy.dreamhost.com
A Happy DreamHost Customer
417 Associated Rd #324
Brea, CA 92821
US
+1.2139471032
Administrative Contact:
willrosecrans.com Private Registrant willrosecrans.com@proxy.dreamhost.com
A Happy DreamHost Customer
417 Associated Rd #324
Brea, CA 92821
US
+1.2139471032
Technical Contact:
willrosecrans.com Private Registrant willrosecrans.com@proxy.dreamhost.com
A Happy DreamHost Customer
417 Associated Rd #324
Brea, CA 92821
US
+1.2139471032
Billing Contact:
willrosecrans.com Private Registrant willrosecrans.com@proxy.dreamhost.com
A Happy DreamHost Customer
417 Associated Rd #324
Brea, CA 92821
US
+1.2139471032
To be fair, it wan't like they were just outputting the wrong units. They were outputting the right units, per the spec. They were just using a different set of units for the internal calculation, and then got bit by precision problems in the conversion. Basically, it was a rounding error. Theoretically, the details of the math could be fairly arbitrary as a "black box API." They just needed an infinite number of bits and it would have worked fine...
Unfortunately, even that's not easy enough for my mom. Nowehere near easy enough, in fact. In order to popularise encrypted email, you have to surrender the idea of out of band key exchange and the concept of web of trust. You also need a highly interoparable way to have it just magically work by default. One good starting place would be a "Public Key At URL" header standard in all email. If you had that, you can imagine a future scenario circa 2015...
Ordinary corporate email user alice@example.com fires up Outlook 2014. A key has been automatically generated for the user without them knowing it on the Exchange server. Alice sends an ordinary unsecured email to bob@othercorp.com without pushing any extra buttons. This is the first time they have corresponded. Alice's email client includes a header for public-key-location which states that her public key is stored at "https://exchange.example.com/keys/alice". Bob doesn't specifically check email headers, so he just sees a normal email in his inbox. He decides to reply. His email client sees that he is sending to an email address with a known public key location, so it downloads alice's key automatically, and uses it to encrypt bob's message to alice so that only she can read it. This fact manifests itself as a discreet "encrypt" checkbox in the compose email window of bob's mail client. He never needs to manually intervene in the process unless he wants to install a key manually, or actively turn off encryption. Most people would never specifically do that.
The technology for that kind of infrastructure has been in place for ages. But, there isn't a critical mass that want's it. The security die hards want a system with manual key verification, and user awareness and training. Microsoft might create something similar to what I describe, but it would only work with Outlook and be explicitly incompatible with anything that isn't an Exchange client. And, they would do all decryption server side with decrypted mail stores so IT can audit corporate email. The overwhelming majority of users just don't care. But, basically one of the big players (Microsoft? Google?) needs to create a whole ecosystem in one swoop, with a massive installed base automatically, in order to get any real traction.
And the rest of us tend to put anything important through a medium other than email. scp for files, ssh tunnels for random things, ssh and talk for nefarious conversations.
In some cases, advertisements are worked on before software even exists in a final form, so it would be impossible to actually use on set. As a result, you get a motion graphics artist doing their best to convey the impression of the UI, but it's not perfect. Even when the software does exist, shooting an actual phone screen with a camera usually results in something very difficult to see, and completely unlike what you experience with your own eyes. So, you shoot with a turned off phone with an actor vaguely pecking at imaginary buttons. When the UI gets comped in, the buttons have to be wherever the actor was poking at. If you used screenshots that look exactly like the actual software, it would be responding in impossible ways at the actor poked where the send an email button goes, but then starts talking into the phone like he is on a call.
So, the best option winds up being a bit impressionistic. It's not perfect, but nothing is.