If the student's goals are to get a marketable career that will last at least until his next career, he needs to learn whatever employers will want him to know, not whatever is deemed the one true definition of computer science.

If the student's goals are to think and act like a computer scientist or a master engineer he needs to take the appropriate classes and gain the appropriate experience.

Anyone who wants to "think like a computer scientists studying memory management" should know and understand the memory management of not only assembler but also other languages that handle memory in other ways, such as traditional C or managed-memory languages like Java. They should also know how different hardware architectures present memory to applications - is the assembler code really running on the bare metal or is the microcode or hardware-virtualization-layer playing games behind your back?

Likewise, the student who wants to think like a master engineer needs to know enough to say "I will choose library A, compiler B, and run-time implementation C, middleware layer D, operating system E, and hardware F over others because together, they provide the best balance of speed, cost, maintenance, ease of programming, and other factors compared to competing products." For some applications, "knowing enough" means knowing enough about memory management to recognize when memory will be an issue that requires engineering attention/optimization and when it won't be an issue.

Here's a trivial example of how the passage of just two years from 1983 to 1985 changed the need to grok memory management:

In 1983, the early public release of MacPaint running on the early public release of MacOS is said to have used all but 384 bytes of the 128KB of the original Macintosh's RAM. Granted, it relied heavily on the routines that were in the original Mac's 64KB of ROM and it used its own spiritual analog of "disk-based memory" by storing most of the image on the floppy drive instead of in RAM. How did it do this? In addition to being written with a significant amount of assembly language code, it's my understanding that either MacPaint or the ROM routines or both used some very tight loops that, if memory were not so tight, would have been "unrolled" for the sake of speed. Today, or for that matter even 2 years later when RAM was relatively plentiful and cheap, a similar program could have been written in a high-level language without any fancy programming and without the need to "page out" the parts of the image that were not visible on the screen. The very task that required intimate knowledge of memory management in 1983 no longer required this knowledge in 1985.

Useful links:

* https://en.wikipedia.org/wiki/...
* http://www.computerhistory.org...
* https://en.wikipedia.org/wiki/...
* https://en.wikipedia.org/wiki/...
* https://en.wikipedia.org/wiki/...
* https://en.wikipedia.org/wiki/...

and links embedded in the pages listed above

You can't change a straight person into a gay person or vice-versa any more than you can change a left-handed person into a right-handed person or vice-versa. Sure, you might have occasional success but your failure rate will likely be well north of 90%.

But you can entice/brainwash/encourage a bisexual person to "pick a preference" and you can entice/brainwash/encourage an ambidextrous person to "pick a preferred hand" with a high level of success as long as you start young and/or are working with someone who isn't "bi/ambidextrous and proud of it."

Part of the "anti-gay fear" and the "recruiting young people into the gay lifestyle" fear that was true a generation or two ago and is still somewhat true now reflects this reality: Parents are concerned that their kids MIGHT lean enough towards bisexuality that they want to "protect" them from anything that would make their kids different from how they want their kids to be.

You can also entice/brainwash/encourage socially normative behavior without changing the person's underlying nature. There are plenty of unmarried people who at one point in their life were sexually promiscuous but later, perhaps because of a religious change of heart, or perhaps because they decided they wanted to be seen as "a responsible, respectable adult" more than they wanted to have sex, they became sexually abstinent. The same goes for people who were formerly into the "party scene" with alcohol or drugs but who now value "respectability" more than the fun that they used to have partying.

You can also change behavior by convincing people that their behavior is harmful to themselves or others. I know someone who was "scared straight" with respect to eating a healthy diet when he was diagnosed with diabetes. He would rather live and be healthy long enough for his grandchildren to grow up than to enjoy the good eats he was used to. I'm sure there are many ex-drunk-drivers who got "scared straight" after either hurting or killing someone, having a near-miss, or having seen someone else hurt someone while driving drunk or having seen someone hurt by a drunk driver.

Some ways to manage sex-offenders include showing them that they are hurting themselves or others (this assumes they were ignorant or buying into "sex doesn't harm children" BS someone else taught them - it doesn't work on people who are incapable of empathy), teaching empathy skills (this works on those with low empathy but who have the capability to have it), scaring/enticing them to moderate their behavior ("we are watching you - you WILL be caught"), or in extreme cases where an uncontrollable mental illness is driving the behavior, isolating them from society after their criminal sentences have been served (the same way any dangerously mentally ill person can be committed before he commits a(nother) crime). This is not an exhaustive list.

At some point, a human other than the intended sender or intended recipient looked at the email.

If Google can see this, maybe they can see the XXX photos my legal-aged wife/girlfriend* and I are sending each other, which frankly is none of their business.

This is yet another reason to encourage widespread adoption of end-to-end encryption.

*okay, okay, HYPOTHETICAL wife/girlfriend - this is news for nerds, after all.

Why put off until tomorrow what you can do today?

Okay, I'll grant you that equipment that uses engines which require more power than today's electric engines of the same size can produce can't feasibly be done with wind or solar. Ditto for portable equipment where the size or weight of today's electric engines + batteries is more than the size or weight of the comparable non-electric engine.

But any mining equipment which could be run off of an electric engine and where the size or weight of an electric engine + batteries is acceptable could be run or recharged off of electric mains. The power on these mains can come from "green" sources, assuming of course that a "green" power plant exists or could be built close enough to attach to that region's power grid. That assumption may not hold in some non-developed countries.

There is less uncertainty and other risks in making and selling mining rigs than in mining.

Also, to "do it right," mining on a large scale requires some some BC-mining expertise that making equipment doesn't have. Granted, this "expertise" isn't very much (yet) - it amounts to things like legal compliance (where applicable - not very many places if any as of today but probably many places soon), whether you want to provide "washing/anonymizing" services and if so at what cost, what is the lowest transaction fee you are willing to accept under a given circumstance (e.g. if electricity costs less at night, you may be willing to take a lower fee), etc.

There is a parallel question in the real world with a parallel answer:
Why do people/companies that make oil-drilling rigs sell them instead of just using them to drill for oil themselves? Answer: Different risks and different areas of expertise. Oil exploration companies have or hire expertise in how to scout for possible deposits, how to negotiate mineral leases, how to operate oil rigs, how to handle legal compliance, etc. etc. - things that the rig-manufacturing companies would prefer not to do.

In the USA you can get a low-end tablet for under $60 easy. In many urban areas you can get 768Kbps internet for under $20/month. If your carrier allows previous-generation modems (some don't) you can get a used modem dirt cheap.

If Mom or Dad has a smart phone that acts like a hotspot you don't even need a separate internet - just make sure the kids don't use up all of your gigabytes (most low-end cell data plans in America are metered or they throttle to "2G" speed after a certan amount of usage each month).

If you have a project that's too big to fit into 1 person's head and you want it to work right and be maintainable, you either have to have a team of people who practically read each other's minds or you have to have a solid design and maintenance process.

Either that, or you have to accept that unless you get lucky or your code is hardly ever used, you will have problems down the line.

Having a lightweight or non-existent process is fine for projects that can stay in one person's head and which won't need to be maintained by anyone other than the original author.

I can see the advantages of cheap, relatively-high-speed paper RAM but remember, we've had high-density paper ROM since the age of micro-fine printing, and low-density paper ROM since the invention of, well, paper.

We've also had very-slow-to-erase "eraseable ROM" on paper since the invention of the eraser.

In prehistoric times, we had it was low-density ROM on cave walls.

From TFS:

For short-range communications between devices operated by human beings, this isn't as hard as one might think.

Let's say I want my cell phone to communicate with a kiosk at McDonald's, without having to rely on the phone network to do the authentication.

Behind the counter, McDonalds has a poster-sized, easy-to-photograph representation of the kiosk's public key.

Now to exchange keys, I walk up to the kiosk and press a button. It puts a random picture on the screen. My phone takes a picture of it, combines it with a random picture I create, my public key, and a suggested random private key, then it encrypts it with the kiosk's public key. My phone tells me to turn it towards the kiosks's camera. It displays the random picture the kiosk created for a few seconds, then the random picture I created for a few seconds, then a pictorial representation of my public key for a few seconds, then a pictorial representation of the entire encrypted message for a few seconds. After all of this is done my phone tells me to flip it around again. The kiosk sends me new shared key that is based on the suggested shared key that I sent to it, but this time it is encrypted with my public key.

Now we can talk and I can place my order and provide my credit card information securely.

This all works because I got the Kiosk's public key from a trusted, independent source - the sign behind the counter that some human being put up and which the McDonald's employees would've noticed if it had changed recently (e.g. if a hacker had replaced the real sign with his own fake one and concurrently replaced the kiosk's public key with one he controlled).

By the way, this is a hypothetical example - there are easier ways to buy burgers than to spend half a minute or more playing "can we trust each other" with a kiosk.

Can this method be defeated? Yes - but you defeat it by removing the assumption that the McDonald's employees are paying attention to their surroundings for any suspicious changes and the assumption that the McDonald's employees are loyal enough to their employer to not "look the other way" if they notice a change or worse, collude with each other to BE the "man in the middle." But at this point, it's no different than walking into a bank and dealing with a crooked bank teller.

It's his deity. He's dyslexic.

As to whether his deity can copulate or not... well, what happens on Mount Olympus stays on Mount Olympus... except in the case of pregnancies - those are the things of which legends are born.

Please forgive me for taking the article summary at face value when it said

The only way that could be true is if there was no properly functioning hardware reset button.

I've been around /. awhile, I really should know better than to assume article summaries are accurate.