Slashdot Mirror

(Because everyone decided to repeat the same mistake.)

Google is still repeating it, sorta. They are writing Magenta in a mix of C++ and C, when they could have used L4 instead of LK to eliminate the C bits, or they could have used Rust for the kernel and solved this mistake once and for all.

While Mozilla isn't the only one who develops it, Mozilla is in the process of requiring the Thunderbird project to be spun out and rely on its own infrastructure and funding. I know because I interviewed with Magnus and Jörg for the consulting project to setup the infrastructure.

Twitter post announcing the position: https://twitter.com/pascalchev...

Actual job posting: http://www.garysguide.com/jobs... (mirror, Mozilla has already removed it from their site)

Mailing list post from Gervase announcing the split: https://lwn.net/Articles/68506...

Conspiracy Theory: Vincent Cerf while employed for Google argues for a 'level playing field' that ultimately helps Google escape the transportation costs of it's massive as-snooping traffic that the NSA considers a benefit to national security. Perhaps less sellable under Trump than Obama post-Snowden. Because despite what the FCC said in 10-201 about the nature of the 'level playing field' I always said to myself that I'd believe it when I saw it. And I've never seen it.

The bottom line- while I may also be able to compete by partnering with
existing cloud infrastructure services companies, am I free to compete on my own, paying the
same published rates for my data traffic on the 'general purpose technology'6 of the internet as
my neighbor?

https://lwn.net/Articles/657561/

http://apps.fcc.gov/ecfs/document/view?id=7522219498

http://cloudsession.com/dawg/downloads/misc/kag-draft-k121024.pdf

https://www.wired.com/2013/07/google-neutrality/

http://www.seattletimes.com/business/google-accused-of-betraying-its-net-neutrality-stance/ (some facts wrong in article)

http://arstechnica.com/information-technology/2013/10/google-fiber-now-explicitly-permits-home-servers/

Yeah.
it would be better to use BSD or Hurd.
But let's face it, the world uses Linux.

And it's not developped by a finnish kid any more :
https://lwn.net/Articles/65463...
(None) 3.9%
(Unknown) 3.5%

The remaining 92,6% is big corps.

I wonder how RHEL and my local IT group can keep the workstation I use in working condition without asking to restart the workstation at all...

I'm a seasoned Linux SA. In my experience, many Linux users are (unwittingly?) betting on known vulnerabilities not being exploited due to Linux having a lower profile and its users having better than average safe computing practices. For example, scummy websites offering "Free email emoticon packs - download HERE (emoticoninstall.sh)" just isn't a thing like it is on more popular systems, but at the same time could be equally dangerous. Kind of like with the elusive Mac virus, we should still be vigilant even if the threat isn't obviously present.

You can confirm with the lsof command if they are installing security updates and not restarting any processes using the affected files. If they haven't asked you to log out weekly then it's extremely likely they are just installing the update files at best. Then of course there's the kernel which flat out requires a reboot to take effect. There's a better chance of snowballs in hell than your RHEL workstation having all affected processes restarted for each update and kernel updates being spliced in without interrupting your use of the system.

Here's the last 20 CentOS security alerts, notice two kernel updates. How do your IT people know (if these were even installed) which are actually resolved?
I only had to click next once or twice to see nss in the list, a library that will be in use by dozens of processes on any system.
It really is a good practice to do a reboot after applying updates or on a schedule to keep everything consistent. Then your admins can say from this point on, 100% of known vulnerabilities have been addressed, because you can't say that by just running a yum update every day.
https://lwn.net/Alerts/CentOS/

CESA-2017:0190 firefox 2017-01-26
CESA-2017:0183 squid34 2017-01-26
CESA-2017:0184 mysql 2017-01-26
CESA-2017:0190 firefox 2017-01-26
CESA-2017:0190 firefox 2017-01-26
CESA-2017:0182 squid 2017-01-26
CESA-2017:0180 java-1.8.0-openjdk 2017-01-21
CESA-2017:0180 java-1.8.0-openjdk 2017-01-21
CESA-2017:0086 kernel 2017-01-19
CESA-2017:0083 qemu-kvm 2017-01-18
CESA-2017:0064 bind97 2017-01-17
CESA-2017:0063 bind 2017-01-17
CESA-2017:0062 bind 2017-01-17
CESA-2017:0063 bind 2017-01-17
CESA-2017:0061 java-1.6.0-openjdk 2017-01-12
CESA-2017:0061 java-1.6.0-openjdk 2017-01-12
CESA-2017:0061 java-1.6.0-openjdk 2017-01-12
CESA-2017:0036 kernel 2017-01-12
CESA-2017:0021 gstreamer1-plugins-bad-free 2017-01-09
CESA-2017:0018 gstreamer-plugins-bad-free 2017-01-09

Here's a good discussion of his rationale for not federating.

Actually not. The fucking link tag didn't get closed. Here: https://lwn.net/Articles/687294/

All binary & lib dirs linked in /usr ?
That's incredibly STUPID
Don't they know why /usr existed in the 1st place ?

If you had read the fffffine article, you'd seen the link to an article that condenses the pros and cons: https://lwn.net/Articles/67007...
Of course they know why /usr existed in the first place.

Basically what it comes down to, is that only embedded systems want that separation. And everyone acknowledges that: "The discussion thus eventually turned toward whether or not Debian would risk losing a significant number of embedded users by not addressing their specific concerns. That question remains open to debate, given its speculative nature."

In the end, it seems the advantages of one /usr directory outweighted the advantages and tradition of separate /usr, /sbin and /lib directories.

I've got no idea how you've managed to get that out of this situation. It appears to me as if you have it completely backwards and that "different perspective" appears to be very contrived.

Not really, take this for example:

Damn I hate people who kill the machine for no good reason - Linus Torvalds.

He is not attacking the idea, he is attacking the person. I understand why he is pissed off, because of how many machines it will fuck up, a totally valid criticism. You don't take it personally because it would be like taking personally a shark trying to eat you, it's just what they are. No one wants to be swimming with a shark when it is hungry though.

Torvalds has a particular vision of what the kernel is and how it should behave. When people do something that interferes with his vision in an unfavourable way he reacts to it almost automatically, you see it all the time, it's impulse control. It's understandable, you don't *have* to take it personally, it's just who they are.

That's what you see when you don't take it personally, the person's message and how they are, because you are in control of your reactions without seeing things through the lens of your own emotion.

We've got Trump saying what is on his mind no matter who he offends all over the media (among many others) and you think Linus has lost it?

On the contrary, I think Linus is a very sane person. I think in time he will see that his attitude is damaging to his vision of the kernel and that when he comes to realise and step beyond his own behaviour he will be much more effective - as will the people around him because they won't have anxiety interfering with their coding.

Trump is a completely contrived character. A psychopath, dressed up as a real estate mogul, dressed up as a potential statesman. People get off on Donald trumpeting his rhetoric because they think they can be him one day.

--Best answer I've seen so far, except for the ZFS responses.

--My question is, how has Synology gotten btrfs to be "stable" when it's still considered to be "experimental" on a regular Linux distro? I've seen reports of people losing all their data on btrfs and still consider it to be at *least* 3-5 years behind ZFS.

https://wiki.archlinux.org/ind...

https://lwn.net/Articles/67681...

The real reason is application compatibility. An operating system is designed to run programs and like it or not Linux is not capable of running the programs the majority of desktop users want to run.

Beyond that there is the infighting and fragmentation. Go try and get a concensus on what Linux distro people should use, some suggest Ubuntu, then others pipe in about all the things wrong with Ubuntu and suggest Mint, then you get the reasons you should never use Mint, and of course you should never use any distro that has systemd, you should use Gentoo and compile it yourself. Why you ask? Well because you can read the sourcecode and see what it does, of course the open source philosophy doesn't work without people inspecting the code. Then you'll have the Unity vs Gnome vs KDE wars.

By this time it has gotten so far away from the idea of installing an operating system that probably won't run your programs that most people don't care anymore.

It's a security/administrative nightmare...
https://lwn.net/Articles/67666...
Please, read what's below the headline...I know that the site's compromise has been fixed and has nothing to do with the OS.

Don't go with Mint: https://lwn.net/Articles/67666...

Interesting read.

I don't know if it's enough to get me to abandon Mint, but I'd definitely be interested to know what distro(s) you'd suggest as an alternative?

Don't go with Mint: https://lwn.net/Articles/67666...

Don't go with Mint: https://lwn.net/Articles/67666...

Never recommend Mint: https://lwn.net/Articles/67666...

It sounds like Lars (owner/creator) is burned out by the ordeal but a handoff of GMANE might be possible. No matter what, I hope Lars is rewarded for all the effort he put into GMANE - it's a fantastic tool.

https://lwn.net/Articles/69440...

"Accordingly, we are pleased to announce an excellent slate of new directors who have agreed to
serve on Tor's board. The old directors have, as of July 12, 2016, elected these directors as the
new Tor board:

Matt Blaze
Cindy Cohn
Gabriella Coleman
Linus Nordberg
Megan Price
Bruce Schneier[1]

Roger Dingledine and Nick Mathewson will continue in their roles as co-founders of the Tor Project,
leading Tor's technical research and development. We will all continue to support Tor's mission,
community, management, and organization; and we are happy to offer Shari, the new board, and the
entire team our help and knowledge. We thank the Tor community for their patience and help in this
transition."

[1] isn't he former DoD or something?

I thought v9v was v9 + VIS instruction set extensions.

> Hitachi SuperH

SuperH gets used a lot in embedded, mobile and automotive applications. The SH3 & SH4 are really quite powerful 32-bit processors with MMUs, and I've always found the SH4 4x4 vector instruction set nifty (and amazingly fast if your problem can fit in that box). The biggest reason to continue SuperH support in Linux is the fact that the patents on the chip have expired and there is an active effort to produce an open source implementation (see: https://lwn.net/Articles/64763...). They currently have SH2 level functionality and are aiming at SH4.

The SH5 was a 64-bit extension of SuperH. It apparently shipped but never made an impact on the market and quickly disappeared, but it does provide a roadmap to 64-bit once a working open source SH4 is solid.

> s390 s390x Some sort of mainframe/large workstation systems I think

Mainframes. Descendants of the IBM/370 and currently call "z/Series" or some such. Latest one is the "z13" line. Processor not derived from PPC or Power, though there is technology overlap. Can run Linux on bare metal or under the z/VM hypervisor.

Bryan O'Sullivan had to stop working on Mercurial around the same time, because his employer used bitkeeper.

Here is a contemporary account based on Tridge's talk at linux.conf.au in 2005

The help command showed that there was a clone command.

"Tridge concluded that perhaps the clone command could be utilized to obtain a clone of a repository. Sure enough, it returned a large volume of output. Even better, that output was a simple series of SCCS files. At that point, the "reverse engineering" task is essentially complete. There was not a whole lot to it. "

Torvalds claims, somewhat exaggeratedly, that he did write the core of git in two weeks

Well, only April 6th 2005 he wrote:

NOTE! BitKeeper isn't going away per se. Right now, the only real thing that has happened is that I've decided to not use BK mainly because I need to figure out the alternatives, and rather than continuing "things as normal", I decided to bite the bullet and just see what life without BK looks like. So far it's a gray and bleak world ;) (...) PS. Don't bother telling me about subversion. If you must, start reading up on "monotone". That seems to be the most viable alternative

On April 21st he announced git.

Seems to me like the "I #Â%#&Â give up, none of these alternatives work I'll just write my own SCM system" phase was 15 days, that's close enough to two weeks for me. Of course I'm sure a lot of the mental churning on what such a system should be like was already done but in terms of coding it seems like he knocked out an initial version in that timeframe.

Why? Python 2 is clearly superior to Python 3. There's no bullshitty "unicode strings" nonsense in it and it's also very stable.

Why "unicode" strings in Python are nonsense? Simple - they are useless for pretty much anything that deals with the real world. Read and weep: https://lwn.net/Articles/68335...

That's the cost of following the law, being nice to environment is a side effect. Apple, as a device manufacturer is under *obligation* to recycle their phones, as long as they want to sell them in 700+ million market called Europe. Here is quick summary of ROHS 2002/95/EC and WEEE 2002/96/EC directives: https://lwn.net/Articles/68380...

Others follow that law by sending their stuff to Africa or China. That's lower cost.

That's the cost of following the law, being nice to environment is a side effect. Apple, as a device manufacturer is under *obligation* to recycle their phones, as long as they want to sell them in 700+ million market called Europe.
Here is quick summary of ROHS 2002/95/EC and WEEE 2002/96/EC directives: https://lwn.net/Articles/68380...

No, Wayland fixes all of this. In fact, this is in part why Mir uses the exact same input library as wayland: libinput.

Responding to my own post because I realized that citation is need:
https://lwn.net/Articles/51737...
https://blog.martin-graesslin....

Wow, you really know how to double down on the stupid. See "Donald Trump".

Or, if you prefer, see what Linus said about it.

Beware of hacked ISOs if you downloaded Linux Mint on February 20th, 2016!

#####

"I'm sorry I have to come with bad news.[1]

We were exposed to an intrusion today. It was brief and it shouldn't impact many people, but if it impacts you, it's very important you read the information below.

What happened?

Hackers made a modified Linux Mint ISO, with a backdoor in it, and managed to hack our website to point to it.

Does this affect you?

As far as we know, the only compromised edition was Linux Mint 17.3 Cinnamon edition.

If you downloaded another release or another edition, this does not affect you. If you downloaded via torrents or via a direct HTTP link, this doesn't affect you either.

Finally, the situation happened today, so it should only impact people who downloaded this edition on February 20th.

How to check if your ISO is compromised?"

Continued @: http://blog.linuxmint.com/?p=2...

[1] Written by Clem on Sunday, February 21st, 2016 @ 1:44 am

#####

https://news.ycombinator.com/i...

https://www.reddit.com/r/linux...

https://lwn.net/Articles/67661...

https://twitter.com/Linux_Mint...

No, it "only leads to other errors".

Funny, I haven't heard of any showstopper bugs in OpenBSD libc - not this year, not ever. And it's ubiquitous, since I'm running it on my phone.

This bug, after ghost, would be a good opportunity to take a step back for a serious assessment of what must be removed for a secure system.

The only POWER CPU most people have any familiarity with would be the PowerPC that could barely run MacOS. I assume the POWER8 is better than the PowerPC, in part because it would be a significant Slashdot story if it was somehow worse.

IFF the hardware becomes popular enough to warrant any attention, Microsoft and other developer shops will compile for it. Currently, it is only supported in Linux because IBM spent a billion to get it supported.

Why do you keep pointing to license agreements? The GPL is not a license agreement, it is just a license.

It does not obligate you to do anything at all, and you don't agree to do anything by "accepting" it, ergo is is NOT a contract.

You are probably talking about live-kernel patching (kGraft - Suse, kpatch - RedHat, sort of similar to ksplice - now Oracle).

Because that is all it is:
security updates without reboot.

Not: new functionality or large bugfixes.

kexec is cool, but kexec just means: faster reboot into new kernel (no waiting on the BIOS, etc.). The old kernel starts a new kernel directly.

The people from CRIU (save and restore running processes) want to combine their solution with kexec so you can do fast upgrades eventually:
"When replacing a kernel on a box we can do it without stopping critical activity. Checkpoint it, then replace the kernel (e.g. using kexec) then restore services back. In a perfect world the applications memory shouldn't be put to disk image, but should rather be kept in RAM."
https://criu.org/Usage_scenari...

I don't think a patch for PRAM has been accepted yet: https://lwn.net/Articles/55704...

The CRIU developers can save/restore a lot of things, but I don't think they can do it for everything yet.

Right now, many companies consider the GPL3 as a definitive non-starter. This comes from reputation, as developpers don't like to read licenses, and trust lawyers on this. And it's always easier for lawyers to say no when they have the smallest of doubts. GPL3 is a part of the reason GCC is being menaced today, as LLVM and Clang have a large corporate backup, sometimes from previous contributors to GCC that do not like it. The fight is not over yet, as GCC continues to attract big names like ARM and Intel, but they are hedging their bets and working with Clang (and Apple) as well.

My opinion is that FSF should try to engage some manufacturers and show them that the GPL3 is not an issue. In the car space, they can be more responsive as they see Google and Apple as threats, not allies, and for them computing is a tactical battle. If HP can end up advocating for the GPL3, it should be possible to work with the Automotive Grade Linux group to show that the GPL3 does not prevent success. It could be an intervention in the compliance conferences, it can be the setup of checklists of things to do, it can be software that makes it easy to fill all requirements, especially around DRM and trusted computing, in a benefical way both for the final user and the manufacturer. But something needs to be done to build communications between the FSF and possible GPL3 users to calm their fears.

Or the FSF can continue to claim that there is no problem with GPL3, and watch as many possible users and contributors avoid them.

That said I tend to agree with the OP on a point: allowing a piece of PHP to auto-update is a recipe for disaster. If you're not "in the biz", use a serious Linux distribution which will handle the packaging and updating for you. That what I do with Owncloud on Debian, and even if I'm a bit behind I'm sure I have a packet correctly updated, which is absolutely not the case with the upstream package. See this article for a discussion about the problem: http://lwn.net/SubscriberLink/...

" To my knoledge linux does not bit bang any common device for any significant amount of time"

You hit the nbail on the head. It is your lack of knoledge (sic) is the issue. Also, who cares if it is a common device or not? That being said, SPI is just one of many bit-banging scenarios that Linux does just fine.

From: http://lwn.net/Articles/664385... It is hosted by the Linux Foundation and sponsored by the Electronic Frontier Foundation, Mozilla, Cisco, and Akamai. Let's Encrypt also has a cooperation agreement with the certificate authority Identrust, which will sign the Let's Encrypt intermediate certificate. This cross-signature from an existing certificate authority will guarantee that the Let's Encrypt certificates will be accepted by all major web browsers.

There is a pretty writeup about modern TLS issues on lwn: http://lwn.net/Articles/664385...
It seems that certificate revocation is not working particularly well in practice. The 90 day duration is meant to help with this, you can simply let the certificate expire.

Well, apparently even the founder of Debian felt he had to move away in this context https://lwn.net/Articles/62189... so I dont think that is a simple as you describe it.

Also, I think there is a misunderstanding about non-systemd packages. Currently, systemd take a place that no init system had. It replaces many parts and software and other software are being made to depends solely on this one. Maintaining non-systemd packages does not mean keep in order what existed before, but writting alternatives to systemd wherever it decides to go.

This powerdevil/upower is an example. There is no going back to pm-utils for upower, even though it used to support it. Now, you need either to use systemd or some ConsoleKit2 that would behave in a similar fashion.

Basically, it looks like maintaining non-systemd packages would mean making a copy of systemd. That looks neither feasible nor sensible. Why would people interested in a systemd-free system write another systemd?

There is "no best way of both worlds". Edmunson wrote it "allows us to throw away large amounts of code whilst at the same time providing a better user experience. Adding it [systemd] as an optional extra defeats the main benefit". There is no throwing away of code and non optional dependancy that allows such a happy ending.

Both in the technical sense and in the human sense.

Technical: People at Linus' caliber understand exactly the rules for signed/unsigned integer promotion and where underflow is defined (as wrap) and where it's undefined[1]. Consequently he wrote perfectly-correct code for detecting the underflow and bailing out safely. Programmers at mere mortal levels of skill, however, routinely mess this up, often causing exploitable security bugs (believe me, I do code security audits as part of a real honest living). My advice for everyone (contra Linus!) is always always always use the compiler intrinsics for integer math. Feel free to decline this advice if you are a Linus level wizard (if you were, of course, you would already feel free to decline it) but if you have to wonder if you are, you probably aren't.

Linus seems to think that the kernel should only be written by folks that don't need that kind of help -- and for that I won't argue with him. It's his baby and he can chose whether to have a small number of über-developers or a larger number of mortals. Which goes straight to the second point:

Human: People at Linus' caliber thrive on negative feedback. At their level, positive feedback means nothing because there's nothing he can learn from someone praising his work. He wrote a kernel, he knows he's good. Meanwhile negative feedback is useful (unless trivially discountable): if the complaint is right, he'll correct something he was doing wrong; if the complaint is wrong, he'll be forced to think through why. In any event, he could never imagine why someone would sugar-coat their opinion on any matter.

So it seems like his mode of communication is meant to answer that question for the former: he wants people of his caliber that don't write ugly code using arithmetic crutches and don't care about strongly worded criticism. There's nothing invalid about that either -- maybe it's true that the best model is that Linuses work in the kernel and the rest of us go up into userland where we use crutches like memory protection and higher-level constructs :-)

[1] And when behavior is undefined, a smarter compiler can remove the code-path entirely -- the kernel itself was hit by such a bug where GCC legally removed a NULL check because the pointer was dereferenced before the check. See also this reference. Then there's the sad fact that people still argue against the clear language rules that say that assert( 100 + some_int > some_int ); can always be optimized away.

For those not wanting to read anything historical. The confrontation comes because the Secure Boot option of UEFI (if enabled) only ships with Microsoft keys in the firmware. Thus, Microsoft's signing service is the only practical signing service and will only sign a PE executable. The solution that Matt and company came up with was to have a module vendor wrap their keys in a PE executable, have Microsoft sign them, and then ship the signed PE executable with the signed Linux kernel module. Verification of the signed Linux module thus requires the Linux kernel to load the PE executable, verify its signature, then extract the vendor keys and continue on.

Linus rightly called out the idea as moronic and stupid. The retorts basically came in the form of "Microsoft created the standard, and is the only viable signing service for the standard". Even though alternative options could of been had, they were deemed to complicated and involved.

Life would of been much easier of Microsoft would just sign X.509 certificates like the rest of the world.

Read more about it here.

It's not about "interminable arguments over the naming", the only one doing that is no else than Matthew, in attempt to pigeonhole his agenda.

This dates way way back to 98. Matthew tried to push gradual openbsd-ish "lock down everything" levels few times, while Linus and his club keeps firm stance "inherited bitmaps or gtfo" every time.

This is ultimately BSD "give user limited but easy to use tool" vs linux "provide powerful [albeit not as intuitive] tools, let user do the job". Think pf vs iptables. I personally stand with linus on this one, as providing flexible tools (instead of easy to use, but limited) is ultimately what made Linux a winner - people can bend the system for more usecases, instead of being restricted by simple and easy to use, but often hopelessly limited tools.

It's not about "interminable arguments over the naming", the only one doing that is no else than Matthew, in attempt to pigeonhole his agenda.

This dates way way back to 98. Matthew tried to push gradual openbsd-ish "lock down everything" levels few times, while Linus and his club keeps firm stance "inherited bitmaps or gtfo" every time.

This is ultimately BSD "give user limited but easy to use tool" vs linux "provide powerful [albeit not as intuitive] tools, let user do the job". Think pf vs iptables. I personally stand with linus on this one, as providing flexible tools (instead of easy to use, but limited) is ultimately what made Linux a winner - people can bend the system for more usecases, instead of being restricted by simple and easy to use, but often hopelessly limited tools.

If it wasn't clear by reading between the lines, I consider a permissive license (like zlib, libPNG, BSD, etc) more suitable than GPLv3 for a reference library if your goal is to ensure broad, industry-wide adoption of a new file format. My assumption is that very few people or organizations will be interested in writing their own library from scratch simply to adopt someone's new file format. Your reasoning seems to be "if it's already difficult, why not make it more difficult still?" which seems a strange argument to make.

That the GPLv3 license hinders broad adoption should be self-evident, as the license specifically prohibits use of the code in non GPL projects. That hardly seems like a "vague claim". That's a simple fact. Perhaps you should read Richard Stallman's very pragmatic view on this matter, as I agree with his reasoning here.

As for the FOSS/GPLv3 thing... The GPLv3 is the most well-known copyleft FOSS license, which means that if you use that license, any FOSS software you release is guaranteed to remain as FOSS-only code. I admittedly could have worded that better.

Fastest will probably be 'Servo', which is the new browser engine by Mozilla.

It's a parallel browser engine, it can render multiple parts at the same time:
https://www.phoronix.com/scan....

It's also written in Rust a language probably less prone to security issues than C++ (which all the other engines are written in).

A general article about Servo:
https://lwn.net/Articles/64796...

But that's already how it works. They eat the cost of development and then find channels to sell it through. There's the odd company that chooses to be in control such as Origin and Blizzard but generally most games are available through most channels. Consoles offer resell of games if the publisher allows it. At least you know when you buy the game if you can or cannot resell later.

but it shouldn't be illegal to crack it

Depends what you mean by crack it. If I crack it so that I can use it without buying into it, I believe it's theft (copyright infringement). If you purchase it, crack it and play it, I don't see a problem with that. I'm pretty sure the publishers won't care either. The problem is those that crack it, distribute the crack and worst host cracked servers for non licensed copies of the game. Meanwhile the company can't profit from that use.

Last I checked you are allowed to reverse engineer anything you want as long as you don't attempt to copy for sale (that's where it becomes illegal). See wiki: https://en.wikipedia.org/wiki/...
This here speaks on both our behalf but mostly says that software reverse engineering is legal in the US as long as you don't reveal trade secrets if applicable (that's where the shit hits the fan IMO). http://lwn.net/Articles/134642...

Fact is, go ahead and reverse engineer anything your purchased because as long as you don't distribute your findings or copy protected content you aren't breaking the law.

Of course your phone used DHCP to assign IP addresses to connected devices, but a DHCP server has nothing to do with NAT. Which NAT daemon do you see running on your Android device? Tethering was introduced in Foryo (2.2) but Froyo was unable to support NAT due to inability to port the required kernel modules. Can it be done in userland? Sure, no reason you can't implement it in DALVIK (Java), but the performance would be shit. Then, there's this discussion. There's plenty more if you Google a bit.

And, again, having spoken with T-Mobile network technicians, the actual people working on the network and not any support tier (hey, it helps to know people), I know I'm right in this instance, at least as far as my carrier is concerned. You aren't going to convince me you know more than they do; especially when you display a complete lack of motivation to research and learn for yourself rather than making the random guesses you think sound most logical.

The still need to support devices not capable of NAT, so they still need the NAT hardware on their end. So, you're getting NAT from your carrier anyway. If your phone is NATing you, too, it's doing you a disservice by killing its own battery faster, passing packets through a slower chain (your device's CPU and RAM), and double-NATing, when the radio chip everythign has to pass through anyway already has the ability to do the routing necessary to simply use the carrier's already-in-place NAT at almost no pwer cost, without delaying packets at all or adding to the load on the device.

You must be an engineer. Not a good one, probably lacking a degree in the field or any practical experience, but an "engineer", for sure.

The Linux Foundation has already given funding to a few open source projects it considers "core" (which includes the original NTP project) and has been trying to assess which other core products are most at risk. From looking at the members page, at least two of the companies you mentioned (Google, Facebook) are part of the Linux Foundation so the giving back has at least started...

The solution is to use /dev/urandom, but only after verifying that the pool has some entropy. Ideally, it would be nice to have an API that allows you to find out how many total bits of entropy have been gathered by the system, regardless of how many remain in the pool at any given point in time. If the system has managed to accumulate a few hundred bits, just use /dev/urandom and get on with life. If it hasn't, use /dev/random and block.

The solution is to use /dev/urandom, but only after verifying that the pool has some entropy. Ideally, it would be nice to have an API that allows you to find out how many total bits of entropy have been gathered by the system, regardless of how many remain in the pool at any given point in time. If the system has managed to accumulate a few hundred bits, just use /dev/urandom and get on with life. If it hasn't, use /dev/random and block.

You could build what you are asking for by using the new (since v3.17 kernel) getrandom() syscall. See the part about emulating getentropy for determining if you've ever had up to 256 bits entropy in its man page for implementing your API suggestion...

That [restoring random seeds] only helps if there's some stored entropy to load during boot. There generally is something to load... how much entropy it has is harder to say.

Well, I'd say that managing entropy for the PRNG is mainly relevant for network-connected servers that need to generate encryption keys all the time. I assume that the timing of incoming network packets counts towards the entropy pool.(*) There should be plenty of network packets to ensure the accumulation of at least a kilobit of entropy during the normal course of operation.

(*) I can't find any list online of linux entropy sources that are used. There is LWN: Appropriate sources of entropy, where it's argued that it's difficult to make a reliable estimate of network-originated entropy. In the comments there, it is argued that one should still use the entropy from network interrupts, even if one chooses not to increase the entropy counter.

Virtualization is a strong candidate because everything can be so samey but it can happen on real hardware too - imagine a trying to generate randomness on a basic MIPS based home router with flash based disks, no hardware RNG, typically booting from a fixed extract RAM disk install and doesn't have hardware clock to save time when powered off but makes ssh certs early during its first boot...

For the interested: Understanding-And-Managing-Entropy-Usage Whitepaper Black Hat whitepaper.

So it seems this is the classic problem that (Linux) programmers are told to use /dev/urandom (which never blocks) and some programs are doing so at system startup thus there's the opportunity for there to be "insufficient" randomness because not enough entropy has been gathered at that point in time. In short: using /dev/urandom is OK but if you are using it for security purposes you should only do it after /dev/random would have stopped blocking for a given amount of data for the first time since system startup (but there's no easy way to determine this on Linux). Or is there? Since the v3.17 kernel there is the getrandom syscall which has the beahviour that if /dev/urandom has never been "initialised" it will block (or can be made to fail right away by using flags). More about the introduction of the Linux getrandom syscall can be read on the always good LWN. And yes the BSD's had defences against this type situation first :-)

So this is bad for Linux systems that make security related "things" that depend on randomness early in startup but there may be mild mitigations in real life. If the security material is regenerated at a later point after boot there may be enough entropy around. If the the system is rebooted but preserves entropy from the last boot this may be mitigated for random material generated in subsequent boots (so long as the material was generated after the randomness was reseeded). If entropy preservation never takes place then regeneration won't help early boot programs. If the material based on the randomness is never regenerated then again this doesn't help. If you take a VM image and the entropy seed isn't reset then you've stymied yourself as the system believe it has entropy that it really doesn't.