devrandomguy

If we're going to do creative difficult things with orbital first stages, then I would like to see them used as space stations. 3.7m OD should be nice and roomy on the inside. Perhaps, a bunch of them could be linked together into a ring? There were ideas like this for the Shuttle's big orange tank, back in the day.

If you want to put the first stage in orbit, then eliminate the second stage engine, and plumb the second stage fuel into the first stage tanks. Replace the central first stage booster's bell with a wider vacuum-optimized bell. Hopefully, the weight saved by eliminating the second stage engine would make up for the reduced efficiency of that central engine, during atmospheric flight.

Easy peasy in KSP. No idea if it is possible IRL.

Yet another use case for solar sail laser arrays: deorbiting clouds of debris and tiny satellites.

If only we had used Lisps for all the things!

We could have had Lisp instead of JS, but no, that would have worked too well; management wants Java. We almost had a Scheme instead of CSS: DSSSL, which could also do structural transformations of the document tree. But once again, no. The simplicity multiplied by the flexibility of a Lisp, equaled unacceptable complexity, for some strange definition of complexity.

XML looks like it really, really wanted to be a Lisp, what with its orderly nesting of tags. I almost wonder if XML stumbled and fell, due to the supporting pillars of parens being knocked out or corrupted, left, right and center.

In Qatar, it is illegal to criticize the ruling family, for example. It is also illegal to promote methods of circumventing the various internet laws, such as VPNs. Sites that are perceived to fall foul of this, get blocked. It is very irritating; I got in the habit of using Tor for everything.

The block looks like this: https://dohanews.co/wp-content/uploads/2014/09/qatar-block.p...

Because fear of the unknown is stronger than fear of the beast.

IMO, assembly will remain an optimal tool for writing simple programs for very small microcontrollers. Consider the ATtiny4, for example, which has 32B ram and 512B of flash for code.

If you can operate within those constraints, then you can build at a <$1 price point, and run on 2mW of power, less current than an LED. Heck, you could run the thing off of a joule thief, and pot the entire assembly in epoxy.

Fitting a pared down libC into that might be possible, but why bother? The system is so small and simple, that the rationale for a high level language doesn't really apply. Most of your code will probably just be bitbanging and setting control registers anyway.

But, most importantly, assembly is just plain fun, which is what will keep you coming back to the platform :)

Brown hat hackers have an incentive to create non-functional ransomware, to spread FUD on the legitimate ransomware. If news spreads that some ransomware does not actually decrypt the files after payment, then potential victims would have a stronger incentive to secure their systems, and a weaker incentive to stockpile ransom funds (wt actual f!)

Then, the onus would once again be on the legitimate ransomware developers to prove their ability to do business, and some sort of Ethereum based automated contract might be an ideal tool for that.

Trampoline would make a nice addition to Ramda. Unless I'm missing it under an unexpected name?

http://ramdajs.com/

Imagine if your next surgeon had this sort of attitude about the cleanliness of her tools, the operating theater, and her staff's equipment. Cleaning is hard, maintaining cleanliness is hard, and pathogens evolve in amazingly clever ways. Perhaps, it will always be possible to propose a theoretical flaw in the procedure.

This is no reason to give up though! It is no excuse for not following best practices, consistently! That is malpractice, when done by a doctor! And their field is at least as complex as our own.

By simplifying the design, until your team can verify its security without throwing up their arms in frustration at the mere prospect. When people's lives are on the line, security is more important than features or convenience.

Critical devices should either be simple, or they should run open source firmware. If governments had required the ability to audit the IC designs that go into medical, military and national infrastructure equipment, then we would now have open source ICs.

I am seeing an incredible resistance to this idea of increasing the situational awareness and capabilities of the people who provision and maintain large deployments. Perhaps it is too soon to propose solutions. Perhaps, today, we should just express solidarity with the victims, and try to warn operators of unaffected, but vulnerable systems to temporarily take them offline.

My apologies to those that I have offended. As a software developer who has struggled for years to articulate the need for transparency and simplicity in our systems, I feel very frustrated right now.

I mean secure as in, when the last of that product line's devices have retired or died of old age, there have been no successful exploits against that product.

Linux is ubiquitous in the data center. We are not a low-value target. Also, corporations with cloud-based infrastructure are more likely to pay large ransoms for their data, especially if it is the backup/archive system that is attacked.

  all software is vulnerable

This is false, and spreads FUD. It does a great disservice to those who do meticulously maintain their systems, to those who sacrifice convenience and beauty for stability and security, to those who take the time to scrutinize other people's work. It is possible to build and deploy secure software.

Linux dominates the datacenter; we are a high value target, and have been for quite some time now.

An open source update can be audited much more easily than a closed source update. It is also usually possible, with OSSW, to find the discussion where the software's developers proposed various solutions, and debated their merits and risks.

If it is infeasible to keep certain critical, networked device up to date, then I propose an alternative solution: those devices should only produce output, they should not read anything at all from their external ports. Their only input, should be their physical user interface. Would that work, for, say, an x-ray machine, or an MRI?

We saw a fictional example of a scheme like this on Battlestar Galactica. Officers phoned and faxed orders around the ship, using simple devices that did not execute software. The CIC had its data punched in by radar operators, instead of networking with shipwide sensors. It was a lot of work, but it did keep working in the face of a sophisticated, combined malware/saboteur attack.

Even information based value has limits. I feel those limits as heat when I push my hardware to its limits. There is also the space limit of how much information I can store, and the time limit of how much information I can experience or learn through my senses.

Those limits are constantly being pushed outwards, but they are not disappearing. Eventually, we might have cities and data centers covering the entire Earth, à la Coruscant. At that point, we will still be constrained by our ability to cool the system, by our ability to efficiently power it all with minimal waste heat, and by the speed of communications through congested networks.

There is no way to know for sure, because we have not embedded telemetry / spyware in open source operating systems.

One of the problems here, is that large organizations are reluctant to update software across a large population of computers. If those updates were smaller, more transparent, and could be separated based on whether they are a security fix, a new feature, or a new tool that allows a 3rd party to monitor user activity, then the sysadmins would be empowered to close security issues quickly, while introducing minimal risk.

OpenSSL was an example of open source done badly; neither of our communities can claim to be universally perfect. The solution, was to fork and replace OpenSSL with a superior project: LibreSSL. That part of the story, is a success for open source. It shows us recovering quickly and permanently from the worst catastrophe imaginable.

I think you are referring to diversity, not obscurity. Diversity does indeed increase the resilience of the network, but there will always be enough common factors across the board, that diversity alone will not suffice.

In the end, the software that we depend on, must be reviewable by anyone who is concerned about it. A prerequisite for that, is that software should be as small, clean, and simple as possible, to encourage such scrutiny. IIRC, the real problem with heartbleed, is that the OpenSSL codebase was a mess, and no-one wanted to work on it.

The relationship between value produced and resources consumed may not be linear, but that does not mean that it is possible to have infinite production, or to produce a change in value from zero resources.

If production is not limited, then we can instantly transform our solar system into a Dyson sphere, right now. What am I not understanding, of this theory?

We are seeing new requests from existing bots, the historical data is not shown on this map.

Thank God for backups! And thank you for making sure people make backups.

My mother is in a similar situation. She is an elementary school teacher, and has little time for unrelated endeavors like this. What time she does have, is spent in the garden, as it should be.

Nevertheless, we are now seeing that the time-cost of closed source software, is greater than that of open-source software. My solution has been to prepare a KDE based distro for her, to work with her, side by side, whenever she needs to learn new tools. It is a good bonding experience, when both people can maintain a positive attitude about it.

The solution to the problem of malware, is education.

There are real limits to everything, because the universe has a finite mass and volume. But, that doesn't mean that it is not possible to engineer a working UBI.

It justifies security updates for all operating systems. It does not justify the installation of spyware or changes to the user interface.

This malware is well written, and uses strong encryption.

I would suggest that you and your father spend the evening reading up on backup practices, and reconsider the value proposition of open source software.

I hope I am not coming off as a smug jerk. My hope is that rather than becoming frustrated and demoralized after an evening of fruitless hacking, you and your uni will recover, and become resilient against future attacks.

What memory management paradigm would you recommend, for an application like this? Let's say, a 1 hour game session generates ~100 GB of transient data, but only 100 MB is needed for what is currently within the camera's view at any one time. How do you keep track of which data is still important, and when do you release memory?

I would be interesting in finding a medical doctor's or a biologist's perspective on this. Suppose we consider the NHS to be a body, in the greater environment of the internet/economy/government. What traits of that environment led to the evolution of this ransomware pathogen? Now that we have had a massive, but not lethal exposure to it, how can we build up an immunity? What changes to the environment would eliminate the refuges of this pathogen?

It is both. What happens if they admit to stealing trade secrets, and clearly intend to continue to compete in the market? Could the judge literally kick them out of the industry, or force the company to disband by labeling it an illegal organization?