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.

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.

I hate to feed a troll, but there's three schools of thought here:

        Cue-Tee
        Cutie
        Cute

And for the record, the first two schools are wrong. Official pronunciation is "cute," according to the developers. This is especially useful when you have QuickTime and Qt things expressed with the same letters. QT is short for QuickTime and is pronounced "cue-tee," but Qt is "cute."

Incidentally the name derives from the archaic Xt library. Which, as far as I know could only be pronounced by stating the letters.

The paint and fuselage material are the most important things on it that they can gather data from that isn't already something they can get their hands on through other channels.

Don't underestimate the value of this. Whether they can build an exact working RQ170 fleet doesn't matter. If they can get one useful free technology out of it, it's a big deal. Something like paint and skin material would potentially be directly applicable to their rockets, which they build for export. If they could trivially do an upgraded stealthier rocket, that pretty much instantly improves the average selling price, which helps the Iranian economy. It also means that scarier weapons are going to be floating around in the world. I can imagine North Korea being crazy enough to shoot at US warships if they thought there was any chance they we couldn't see the rockets coming, and they could insist they had no idea why our destroyer exploded.

Actually deploying an RQ170 fleet requires a massive support infrastructure outside of the RQ170 fleet itself, so I don't think direct copying was ever the primary concern in the event of a loss of vehicle like this. It's the peripheral stuff. The design of an antenna. The ingredients in the paint. Some cleverly designed duct in the exhaust system. All that kind of stuff has the potential to inspire somebody working in a completely different project.