What you've described aligns well with my experience of the times, and I agree that the dissolution of the family, and particularly its impact on child-rearing and wage levels, has a lot to do with where we've ended up. However in my estimation, the role of mass marketing and the rise of consumerism also played a large role. It seemed that during the 1980's, the status of capitalism was raised to the level of a deity, with a significant number of people actually embracing the premise that "greed is good". Many still do, and not just Boomers.
But I particularly like the question on which you concluded:
Since there isn't, nor shouldn't be, any going back on equality and equal opportunity, how do we incentivize the return to home of one partner in a family, there by reeling back in the inflated workforce, thereby forcing up real wages and helping restore a solid middle class?
I don't think one partner necessarily has to leave the workforce entirely, but we do need to get back to a state where one full-time job or two half-time jobs is enough to support a family (and as you say, without going backward). I don't know how to do that, but as a general heuristic, I'd start by looking for policies and forces that are moving us in the wrong direction, and try to eliminate or reverse them. If this Information Age we're in is all it's supposed to be, there should be some way to get there.
"Full stack" is just another in a long line of terms such as "rockstar", "guru", "code ninja", or "jedi". I'm sure that some people who have used these terms have some more specific meaning in mind, but most of the people who use it just mean "someone who knows what the hell they're doing". And keep in mind that these are mostly people who don't know what they're doing.
When I read a job ad that includes "full stack", I interpret it as people looking for a savior. I ask myself if I think I could save them, and then whether I'd want to. The answer to at least one of those is usually "no".
Savior! I like the sound of that! Let's make that the new hotness in software job ads.
Started in 1969 at age 16, using SEL-840MP (FORTRAN and assembly), PDP-5 (machine code and BASIC), and Tymshare (CAL). Still employed as a developer today, using Scala, Python, and JavaScript. Just finished my Deep Learning specialization on Coursera with Andrew Ng.
Not on any prescription medications yet. I think I can take this in a few years.
I would definitely support the use of an open-source algorithm (and open-source data) to draw districts, as an improvement over the current methods.
However, I also agree with you that geographical boundaries as a basis for representation are largely obsolete. My thought is that it ought to based on some kind of sanctioned "interest groups", where each person is permitted to be a registered member of a smallish number of groups. An interest group would have representation based on the size of its membership. There might need to be a recurring "open enrollment" period in which people could change their group memberships, in order to provide some stability, but interest groups would be expected to come and go over time. Obviously nothing stops people from forming geographical interest groups, given enough people.
Of course this is a radical departure from the current system, and we should be concerned about whether it would be an improvement. But it could be implemented on a purely advisory basis, where the rules are established, representatives are elected for the interest groups, and these representatives vote on everything the House votes on. Then the voting results are published, and we can have a discussion about which system is better at representing us. This also gives people enough time to become accustomed to the interest group system, which hopefully would avoid some of the instability of its initial implementation.
Delivery bots use much of the same hardware and software as self-driving cars, but have market pressures toward lower cost. If they are mass-produced, this will bring down the cost of self-driving cars to the point where even economy cars can be self-driving. Also the AI problem that delivery bots face is arguably more difficult than a self-driving car, in that pedestrian traffic is much less regulated. So they might also drive advances in machine learning from which self-driving cars will benefit.
On the other hand, if delivery bots start injuring a lot of people, the backlash may extend to self-driving cars as well.
Unfortunately our usual method for ascertaining identity is based on an assumption of privacy of certain personal information. The loss of privacy represented by this breach is certainly something deserving of our outrage. But all that justifiable outrage is dwarfed by the implications of no longer having a reliable way to establish identity in a mobile and technological society. While there is still time before the stolen information is widely disseminated, we need to use the doomed current system to bootstrap an identity system which does not rely on information privacy. Such a system probably should be based on some kind of multi-factor authentication, including both biometrics and digital tokens.
Just imagine having no way to prove who you are. It is one thing to have an individual identity thief steal your identity. It is another thing altogether for there to be no meaningful way to define your identity. Yes, we all have DNA, and most of us have fingerprints, but if our biometrics are not associated with our digital identities, then our digital identities are up for grabs.
From where I'm sitting, it looks like the fundamental infrastructure of our society is being undermined. I don't how much is due to cyber-attacks by foreign governments, and how much is due to glaring flaws in our systems being exploited by individuals. But I do know that if we don't start recognizing and solving problems aggressively, we are headed for some kind of collapse.
I started using Scala in 2011. The tooling was very rough at first, but I really liked the language as an alternative to Java. Since then I've adopted a progressively more functional style in Scala, and found it to be a very natural way to think about code. Some of my code is multi-threaded, and using immutable data structures, I find I spend a lot less time worrying about locking. And the tooling is now fairly reasonable in my opinion. Scala's interoperability with Java was a big selling point in the early days, but the Scala ecosystem is now getting to the point where it stands on its own rather well.
A really great development in the Scala world is Scala.js, which transpiles Scala to JavaScript. I despise JavaScript for any development larger than a page of code, so Scala.js was a welcome relief. If you work on large JavaScript apps, do yourself a favor and check out Scala.js. I look forward to the day when WebAssembly matures enough to be a target for Scala compilation. Hopefully then JavaScript will fade away, and someday it will just seem like a bad dream.
We don't know enough about geoengineering to be reasonably certain that our attempts wouldn't make things worse. But when things get bad enough, there's no doubt that we'll be trying all kinds geoengineering stunts, and in a completely uncoordinated way. It would be nice if we could stop making the problem worse, but there's a distinct possibility that it has already gone too far, that we've already crossed a tipping point, where positive feedback cycles make climate change inevitable.
The climate change deniers, at least the cleverer ones, are fond of pointing out how current climate models are lacking in accuracy. Personally I believe they are accurate enough to show that we have a bad problem that is only going to get worse. But I don't think they're accurate enough to predict the results of various geoengineering interventions that are contemplated. So we do need better models. Perhaps we could get some agreement on that point, and maybe some funding to make it possible.
What I would like to see is something like the International Geophysical Year, except with commitment to sustain that kind of effort for a decade. We need to increase the resources dedicated to data collection, as well as improving our geophysical models. And it needs to be an international effort, with all the data made freely accessible to everyone. By keeping the effort going for a decade, there is also a chance that a whole generation of young people might be inspired to pursue a career in earth sciences.
Crockford is half-right. We need to get rid of spaces too. I understand that linear text is a very versatile way to express programs, but it really lacks expressive power. Basically almost all of its expressive power comes from the syntax of the language you're using. Maybe that's a small part of why we have so many languages. Imagine if code were written in something like HTML, and when you edit it, your CSS (or CSS-like) settings determine how it looks. In fact you might have different CSS settings to emphasize different things in the code, with some parts being visible only in certain views. Imagine tools which could analyze the code in some way, perhaps involving external data such as a run profile, or a repository history, and generate a new view.
I understand that this would require a lot of tooling. I also think that any approach that doesn't work for all popular languages is not going anywhere. But there are a lot of concepts which are common across programming languages. Obviously one of the tools that would be needed is one that takes a linear text file in some language, and uses knowledge of that language to produce a marked-up output. We already have editors which understand something about specific languages, but they need to also understand the markup. For compilation, I think it should be possible to have a tool to strip out the markup, which works for any language.
Jupyter Notebooks are an interesting development in programming expressiveness. But their focus seems to be more on expressing the integration of the program code and the results of running the program. I actually think that's a great way to present scientific results. But when it comes down to code blocks in a notebook, it's back to linear text. It's ironic really, since the linear text actually is embedded in markup.
Look, I know it took the prokaryotes a long time (~1 billion years) to evolve into eukaryotes, but it was worth it, wasn't it? And what I'm proposing is not nearly as difficult.
I like a memory-safe language as much as the next person, but software security really is an open-ended problem. My language may prevent me from making a string that overflows its memory, but if the string I'm building happens to be a SQL query, my code could still to vulnerable to SQL injection. Of course there are several ways to build SQL interfaces which don't allow unchecked strings as queries.
The point is that the SQL injection vulnerability is completely analogous to the string overflow vulnerability. Strings were originally implemented as abstractions in languages which had no concept of "string". There have been many such implementations of strings, and a good fraction of them are not memory safe. But now we also have languages which implement memory-safe strings as an abstraction of the language. And people have used these languages to implement a new abstraction, SQL. Again, there are many implementations. Some are safe from SQL injection. Some are not. The ones which are not safe actually may be simpler to use from a naive point of view - like just building a string and passing it to a function. Some programmers may find that more appealing than an API which requires multiple calls or multiple parameters to make a query. It doesn't require them to learn a new abstraction.
Software security problems will always exist, as long as we continue to build higher-level abstractions with APIs which allow the abstraction to be subverted. Even when you have a safe API to a new abstraction, there's an excellent chance someone will come along an implement a "simpler" API, which is simpler mostly because it is vulnerable.
I'm talking about differentials in force with respect to a system capable of extremely non-linear responses. When polar ice melts, much of the weight that was on one plate moves to adjacent plate(s), so the force on the plate where the ice was decreases, and the force on the adjacent plate(s) increases. The change in the difference in force between the plates could exceed the weight of the ice. (And it could be a positive or negative change, depending on the relationship of the plates. A negative change could reduce the static friction enough to trigger a quake. A positive change could increase the stress enough to do it.) The changes in force may not amount to much in terms of magnitudes of the total forces in play, but it could easily be enough to trigger quakes which otherwise might not have happened for thousands of years.
An earthquakes occurs when the static force of friction at a point of geologic stress is overcome, or when the force on a geologic structure exceeds its breaking point. It is an extremely non-linear response, which can be triggered by small changes in these forces. Given that, it would be surprising if tidal effects were not correlated with earthquakes.
As the polar ice melts and its weight is redistributed over the oceans, I expect this also will result in sufficient changes in tectonic forces to trigger more earthquakes, and perhaps volcanic activity as well. It wouldn't surprise me if even changes in atmospheric pressure are sometimes sufficient to trigger a quake.
I particularly would like to see a resurgence of OS research. Things have changed enough in both the hardware and the application landscape since Windows and Linux were designed that I think it would be worthwhile to revisit the questions of what an OS can and should be. But in my view the real problem for the commercial success and/or widespread deployment of a new OS is not so much legacy applications as it is device driver support for the very broad range of devices that are found across the major hardware platforms. It would not surprise me if the volume of device driver code for Windows and Linux (and maybe even Android and iOS) exceeds that of the rest of the OS. In contrast, support of legacy applications can usually be achieved through a compatibility API or container approach.
Ideally I think device drivers should be written in a language which supports a level of abstraction which is at least somewhat OS-agnostic.Then, even in cases where the device manufacturer was unwilling to provide source code, an OS developer could provide the manufacturer with a compiler that would generate a binary for their OS. But the marketing obstacles to such an approach probably far outweigh the technical challenges of its implementation.
As with the design of operating systems, it makes sense to distinguish between policy and mechanism. Science and rationality may or may not be a sufficient basis for creating policies. And here by "policy" I mean things like "people should be equal before the law", "healthcare should be a right", "what's good for Wall St. is good for America", "all citizens should be armed to the teeth", "Mars colonization should be our highest priority". That is, policies are goal statements, and reasonable people can certainly disagree about what our goals should be as a society. Mechanisms are the means we use to achieve our goals, that is, the means by which policies are implemented. So a policy might be: "wealth inequality should be bounded", and mechanisms to achieve it might include "progressive income tax", "subsidies for the poor", or "universal basic income". Given a policy, science and rationality are certainly applicable to designing and evaluating the efficacy of mechanisms to achieve the policy.
Our biggest problem is that most of our political discourse is consumed with debating what we call policies, but which are usually mechanisms to achieve some policy. The policy is seldom explicitly stated and almost never debated, while the participants in a typical political debate take it for granted that everyone accepts whatever implicit policy their proposed mechanism seeks to achieve. But even worse, we implement mechanisms without ever tying them to an explicit policy goal, which makes it difficult to determine whether a given mechanism is working. Politically you get a situation where anyone who questions a mechanism is assumed to be disagreeing with the unstated policy behind the mechanism. The result is that bad mechanisms become entrenched, and are no longer subject to rational or scientific examination. And that just sucks.
If I could interject one question into every political debate, it would be: what are you trying to achieve? And if I could have a second question it would be: how will you know if you've achieved it?
I had an excellent mentor at NASA at age 16. Learned about high-level languages and algorithms using the CAL language on Tymshare. Learned about how computers actually work by toggling in programs through console switches on a PDP-5. Learned how to code efficiently mostly by reading other people's code. Learned FORTRAN IV from McCracken's book. Read a lot of computer manuals, back when computers came with full documentation sets.
Still working as a developer at age 63, and still love programming. These days I mostly use Scala and Python, and when I must, JavaScript. In my spare time I pursue my passion, which is machine learning, taking online classes and working on Kaggle competitions.
Not just a single disaster. Just as we've seen more frequent and more powerful storms in recent years, so too I expect there will be more frequent and more powerful earthquakes, including the possibility of tsunamis. More and larger volcanic eruptions would not surprise me. I expect most of the action would be around the boundary of the Pacific plate. But things could get interesting on the mid-Atlantic ridge as well.
The consequences of this on civilization would be fairly devastating. Besides lives lost in individual incidents, there could be hundreds of millions of refugees. Economic collapse would surely follow, straining our political and social institutions to the breaking point. Much of the infrastructure which supports our technology also would be severely impacted. Major ports may be destroyed by tsunamis or earthquakes, disrupting supply chains for food, and causing food shortages, even assuming that food production itself remains intact. Ultimately a sizable chunk of the human population will perish. But unless Earth goes the way of Mars or Venus, humanity will survive and over time, adapt.
It's useless to debate whether this is a natural cycle or a result of human activity. It would be great if we could limit our carbon emissions, but I fear we're already two or three decades too late. What matters now is trying to understand what is happening, anticipate the possible consequences, and prepare. What we need is something like the International Geophysical Year, except that intensive level of research needs to be sustained for at least a decade.
The article says it's nothing to worry about. Well that's what they said to Jor-El, and you know how that turned out.
The shift in mass distribution caused by melting ice will cross the boundaries of tectonic plates, changing the relative pressure on adjacent plates. This will likely lead to increased earthquake and volcanic activity. On the bright side, the ash from the volcanoes may limit global warming (maybe even trigger an ice age), and deformations of the sea floor may reduce sea level rise (or make it worse). Another possible impact is the triggering of a geomagnetic reversal.
The political debates about climate change are futile. What we should be discussing is whether we know enough about how this planet works (and have the technology) to attempt some kind of active intervention, such as carbon sequestration or actually blocking sunlight from space. But we'll probably just end up fighting over whatever habitable parts of the planet remain. Maybe the survivors will be wiser.
They dont really give a shit about the data in this case, they want to cow the tech sector into not making their jobs harder.
Maybe they care about the data, but it's likely they have other ways to brute force the passcode. This battle with the tech sector over encryption has been ongoing for more than a decade. What's different about this case is that it is the best opportunity the government has had to use fear of more mass killing to shut down the thinking part of the average person's brain. Their goal is to ensure that they have the keys to decrypt anything encrypted by the general public. (Anybody remember key escrow?)
Anyone with a basic technical understanding of how encryption works knows that there is no way to stop a knowledgeable person from implementing encryption in software, and keeping their keys private. So this is really about preventing the average person who lacks that knowledge from having unbreakable encryption. It's interesting that the situation with the general public and firearms is a similar situation, and in fact cryptography was once classified as a munition. It seems to me that a liberal interpretation of the Second Amendment might apply to encryption. I point that out especially for those of you who feel entitled to assault weapons under the Second Amendment.
Personally, I think we need to look at personal devices, and perhaps even our use of search engines, as extensions of our minds and as such, should be treated by the law with the utmost concern for privacy. After all, the technology to actually read minds is advancing, and the day may come when the precedents we set today for our personal devices are applied to our brains.
Just imagine, there could be a phone app that displays an arrow to show the user which way to walk. Using the Lidar to detect obstacles, the app could enable a phone zombie to become almost self-driving, avoiding obstacles and other people. Almost like a real person.
With self-driving cars I expect parking will become like having valet parking everywhere. Think of how guests arrive and leave at a large hotel. There will need to be a reasonable sized area where cars can come and stop to pick up and drop off passengers and their stuff. Once empty, the cars will go and park themselves in high-density fashion. Your typical Safeway parking lot will need to be reorganized to accommodate this.
There will be an opportunity to reduce the space allotted to parking at many places.
I first learned machine language on a PDP-5, which was similar to the PDP-8, but limited to 4KB of memory. Mostly I just used it to toggle in small programs through the console switches, but I think we got the FOCAL interpreter running on it at one point. Those were the days. To think now there is a generation of programmers who have known nothing but JavaScript.
Of course vulnerabilities remain. But when you're deliberately aiming for a secure *system*, they're a lot less impactful. Kinda like how turning ASLR on simply nullifies entire classes of vulnerabilities. MULTICS, according to your paper, didn't have problems with buffer overflows. Thirty years ago, this was a solved problem. Why is it an ongoing problem now?
Because programming languages like C/C++ are still in wide use. I suppose most people who still use these languages would tell you that they must, for reasons of efficiency. Then they would start talking about how their application can't tolerate pauses for garbage collection. But of course you could have a language which supports manual allocation of data types, with a maximum length that is enforced at runtime.
I've addressed why I think software engineering hasn't progressed more in a previous post. The argument I make there about hobbyists designing languages and lack of industry support for standardization also apply to software security. But the problem of security is open-ended. We could have better languages which prevent all kinds of abuses of the hardware-level machine model, languages in which buffer overflows and stack overflow exploits are impossible. But then someone writes a program that builds a SQL query in a string, but doesn't take the necessary precautions, and you have SQL injection. Now the SQL interpreter is in some sense another level of virtual machine which needs to be protected from abuse. It's not hard to do that if your program creates SQL queries using a data structure that supports a higher level of abstraction than strings. But if a SQL client library is provided, and it takes a SQL query as a string, building a safer level of abstraction on top of that probably isn't going to occur to most programmers. Nor will they necessarily take the time to discover that someone else has implemented a higher-level interface. Strings are what they know, and strings are what they'll use.
Likewise, when JavaScript was added to the browser, it created a whole new world of potential security vulnerabilities. Brendan Eich may not have been a hobbyist in the strictest sense, since he was being paid. But he was working under a very tight schedule which prioritized functionality over security. And I suspect even he would admit to having made a number of rookie mistakes in language design. More importantly though, is that some kind of client-side scripting of HTML was virtually inevitable. There is an inexorable force toward adding more functionality to successful software. And whenever new abstractions are created, or new interpreters built, there is the potential for new kinds of security vulnerabilities which can exist regardless of how secure the underlying infrastructure may be.
This is not to say that I believe secure software is impossible. But it is a moving target that can't be addressed simply by instilling in programmers a comprehensive list of secure programming DOs and DON'Ts. Programmers really need to be able to recognize when their code may be creating new kinds of security vulnerabilities.
In spite of the fact that security was a top priority for MULTICS, in spite of the fact that it was written in PL/I rather than C, in spite of the fact that it was a very small, less complex system by today's standards, in spite of the fact that it was more secure than most modern systems, MULTICS was easily penetrated during the security evaluation. So I maintain my original position that writing secure software is hard. So hard that even when people are diligently trying to write secure software, vulnerabilities remain.
MIT's ITS was another system derived from MULTICS, and deliberately insecure. It even had a non-privileged "crash" command to crash the system, and logins were optional.
Slashdot Mirror
What you've described aligns well with my experience of the times, and I agree that the dissolution of the family, and particularly its impact on child-rearing and wage levels, has a lot to do with where we've ended up. However in my estimation, the role of mass marketing and the rise of consumerism also played a large role. It seemed that during the 1980's, the status of capitalism was raised to the level of a deity, with a significant number of people actually embracing the premise that "greed is good". Many still do, and not just Boomers.
But I particularly like the question on which you concluded:
Since there isn't, nor shouldn't be, any going back on equality and equal opportunity, how do we incentivize the return to home of one partner in a family, there by reeling back in the inflated workforce, thereby forcing up real wages and helping restore a solid middle class?
I don't think one partner necessarily has to leave the workforce entirely, but we do need to get back to a state where one full-time job or two half-time jobs is enough to support a family (and as you say, without going backward). I don't know how to do that, but as a general heuristic, I'd start by looking for policies and forces that are moving us in the wrong direction, and try to eliminate or reverse them. If this Information Age we're in is all it's supposed to be, there should be some way to get there.
"Full stack" is just another in a long line of terms such as "rockstar", "guru", "code ninja", or "jedi". I'm sure that some people who have used these terms have some more specific meaning in mind, but most of the people who use it just mean "someone who knows what the hell they're doing". And keep in mind that these are mostly people who don't know what they're doing.
When I read a job ad that includes "full stack", I interpret it as people looking for a savior. I ask myself if I think I could save them, and then whether I'd want to. The answer to at least one of those is usually "no".
Savior! I like the sound of that! Let's make that the new hotness in software job ads.
Could ultraviolet lamps slow the spread of flu?
This could make a big difference if it proves safe.
Started in 1969 at age 16, using SEL-840MP (FORTRAN and assembly), PDP-5 (machine code and BASIC), and Tymshare (CAL). Still employed as a developer today, using Scala, Python, and JavaScript. Just finished my Deep Learning specialization on Coursera with Andrew Ng.
Not on any prescription medications yet. I think I can take this in a few years.
I would definitely support the use of an open-source algorithm (and open-source data) to draw districts, as an improvement over the current methods.
However, I also agree with you that geographical boundaries as a basis for representation are largely obsolete. My thought is that it ought to based on some kind of sanctioned "interest groups", where each person is permitted to be a registered member of a smallish number of groups. An interest group would have representation based on the size of its membership. There might need to be a recurring "open enrollment" period in which people could change their group memberships, in order to provide some stability, but interest groups would be expected to come and go over time. Obviously nothing stops people from forming geographical interest groups, given enough people.
Of course this is a radical departure from the current system, and we should be concerned about whether it would be an improvement. But it could be implemented on a purely advisory basis, where the rules are established, representatives are elected for the interest groups, and these representatives vote on everything the House votes on. Then the voting results are published, and we can have a discussion about which system is better at representing us. This also gives people enough time to become accustomed to the interest group system, which hopefully would avoid some of the instability of its initial implementation.
So we could just do this now. Who's with me?
Delivery bots use much of the same hardware and software as self-driving cars, but have market pressures toward lower cost. If they are mass-produced, this will bring down the cost of self-driving cars to the point where even economy cars can be self-driving. Also the AI problem that delivery bots face is arguably more difficult than a self-driving car, in that pedestrian traffic is much less regulated. So they might also drive advances in machine learning from which self-driving cars will benefit.
On the other hand, if delivery bots start injuring a lot of people, the backlash may extend to self-driving cars as well.
Unfortunately our usual method for ascertaining identity is based on an assumption of privacy of certain personal information. The loss of privacy represented by this breach is certainly something deserving of our outrage. But all that justifiable outrage is dwarfed by the implications of no longer having a reliable way to establish identity in a mobile and technological society. While there is still time before the stolen information is widely disseminated, we need to use the doomed current system to bootstrap an identity system which does not rely on information privacy. Such a system probably should be based on some kind of multi-factor authentication, including both biometrics and digital tokens.
Just imagine having no way to prove who you are. It is one thing to have an individual identity thief steal your identity. It is another thing altogether for there to be no meaningful way to define your identity. Yes, we all have DNA, and most of us have fingerprints, but if our biometrics are not associated with our digital identities, then our digital identities are up for grabs.
From where I'm sitting, it looks like the fundamental infrastructure of our society is being undermined. I don't how much is due to cyber-attacks by foreign governments, and how much is due to glaring flaws in our systems being exploited by individuals. But I do know that if we don't start recognizing and solving problems aggressively, we are headed for some kind of collapse.
I started using Scala in 2011. The tooling was very rough at first, but I really liked the language as an alternative to Java. Since then I've adopted a progressively more functional style in Scala, and found it to be a very natural way to think about code. Some of my code is multi-threaded, and using immutable data structures, I find I spend a lot less time worrying about locking. And the tooling is now fairly reasonable in my opinion. Scala's interoperability with Java was a big selling point in the early days, but the Scala ecosystem is now getting to the point where it stands on its own rather well.
A really great development in the Scala world is Scala.js, which transpiles Scala to JavaScript. I despise JavaScript for any development larger than a page of code, so Scala.js was a welcome relief. If you work on large JavaScript apps, do yourself a favor and check out Scala.js. I look forward to the day when WebAssembly matures enough to be a target for Scala compilation. Hopefully then JavaScript will fade away, and someday it will just seem like a bad dream.
We don't know enough about geoengineering to be reasonably certain that our attempts wouldn't make things worse. But when things get bad enough, there's no doubt that we'll be trying all kinds geoengineering stunts, and in a completely uncoordinated way. It would be nice if we could stop making the problem worse, but there's a distinct possibility that it has already gone too far, that we've already crossed a tipping point, where positive feedback cycles make climate change inevitable.
The climate change deniers, at least the cleverer ones, are fond of pointing out how current climate models are lacking in accuracy. Personally I believe they are accurate enough to show that we have a bad problem that is only going to get worse. But I don't think they're accurate enough to predict the results of various geoengineering interventions that are contemplated. So we do need better models. Perhaps we could get some agreement on that point, and maybe some funding to make it possible.
What I would like to see is something like the International Geophysical Year, except with commitment to sustain that kind of effort for a decade. We need to increase the resources dedicated to data collection, as well as improving our geophysical models. And it needs to be an international effort, with all the data made freely accessible to everyone. By keeping the effort going for a decade, there is also a chance that a whole generation of young people might be inspired to pursue a career in earth sciences.
Crockford is half-right. We need to get rid of spaces too. I understand that linear text is a very versatile way to express programs, but it really lacks expressive power. Basically almost all of its expressive power comes from the syntax of the language you're using. Maybe that's a small part of why we have so many languages. Imagine if code were written in something like HTML, and when you edit it, your CSS (or CSS-like) settings determine how it looks. In fact you might have different CSS settings to emphasize different things in the code, with some parts being visible only in certain views. Imagine tools which could analyze the code in some way, perhaps involving external data such as a run profile, or a repository history, and generate a new view.
I understand that this would require a lot of tooling. I also think that any approach that doesn't work for all popular languages is not going anywhere. But there are a lot of concepts which are common across programming languages. Obviously one of the tools that would be needed is one that takes a linear text file in some language, and uses knowledge of that language to produce a marked-up output. We already have editors which understand something about specific languages, but they need to also understand the markup. For compilation, I think it should be possible to have a tool to strip out the markup, which works for any language.
Jupyter Notebooks are an interesting development in programming expressiveness. But their focus seems to be more on expressing the integration of the program code and the results of running the program. I actually think that's a great way to present scientific results. But when it comes down to code blocks in a notebook, it's back to linear text. It's ironic really, since the linear text actually is embedded in markup.
Look, I know it took the prokaryotes a long time (~1 billion years) to evolve into eukaryotes, but it was worth it, wasn't it? And what I'm proposing is not nearly as difficult.
Waymo
I like a memory-safe language as much as the next person, but software security really is an open-ended problem. My language may prevent me from making a string that overflows its memory, but if the string I'm building happens to be a SQL query, my code could still to vulnerable to SQL injection. Of course there are several ways to build SQL interfaces which don't allow unchecked strings as queries.
The point is that the SQL injection vulnerability is completely analogous to the string overflow vulnerability. Strings were originally implemented as abstractions in languages which had no concept of "string". There have been many such implementations of strings, and a good fraction of them are not memory safe. But now we also have languages which implement memory-safe strings as an abstraction of the language. And people have used these languages to implement a new abstraction, SQL. Again, there are many implementations. Some are safe from SQL injection. Some are not. The ones which are not safe actually may be simpler to use from a naive point of view - like just building a string and passing it to a function. Some programmers may find that more appealing than an API which requires multiple calls or multiple parameters to make a query. It doesn't require them to learn a new abstraction.
Software security problems will always exist, as long as we continue to build higher-level abstractions with APIs which allow the abstraction to be subverted. Even when you have a safe API to a new abstraction, there's an excellent chance someone will come along an implement a "simpler" API, which is simpler mostly because it is vulnerable.
I'm talking about differentials in force with respect to a system capable of extremely non-linear responses. When polar ice melts, much of the weight that was on one plate moves to adjacent plate(s), so the force on the plate where the ice was decreases, and the force on the adjacent plate(s) increases. The change in the difference in force between the plates could exceed the weight of the ice. (And it could be a positive or negative change, depending on the relationship of the plates. A negative change could reduce the static friction enough to trigger a quake. A positive change could increase the stress enough to do it.) The changes in force may not amount to much in terms of magnitudes of the total forces in play, but it could easily be enough to trigger quakes which otherwise might not have happened for thousands of years.
An earthquakes occurs when the static force of friction at a point of geologic stress is overcome, or when the force on a geologic structure exceeds its breaking point. It is an extremely non-linear response, which can be triggered by small changes in these forces. Given that, it would be surprising if tidal effects were not correlated with earthquakes.
As the polar ice melts and its weight is redistributed over the oceans, I expect this also will result in sufficient changes in tectonic forces to trigger more earthquakes, and perhaps volcanic activity as well. It wouldn't surprise me if even changes in atmospheric pressure are sometimes sufficient to trigger a quake.
I particularly would like to see a resurgence of OS research. Things have changed enough in both the hardware and the application landscape since Windows and Linux were designed that I think it would be worthwhile to revisit the questions of what an OS can and should be. But in my view the real problem for the commercial success and/or widespread deployment of a new OS is not so much legacy applications as it is device driver support for the very broad range of devices that are found across the major hardware platforms. It would not surprise me if the volume of device driver code for Windows and Linux (and maybe even Android and iOS) exceeds that of the rest of the OS. In contrast, support of legacy applications can usually be achieved through a compatibility API or container approach.
Ideally I think device drivers should be written in a language which supports a level of abstraction which is at least somewhat OS-agnostic.Then, even in cases where the device manufacturer was unwilling to provide source code, an OS developer could provide the manufacturer with a compiler that would generate a binary for their OS. But the marketing obstacles to such an approach probably far outweigh the technical challenges of its implementation.
As with the design of operating systems, it makes sense to distinguish between policy and mechanism. Science and rationality may or may not be a sufficient basis for creating policies. And here by "policy" I mean things like "people should be equal before the law", "healthcare should be a right", "what's good for Wall St. is good for America", "all citizens should be armed to the teeth", "Mars colonization should be our highest priority". That is, policies are goal statements, and reasonable people can certainly disagree about what our goals should be as a society. Mechanisms are the means we use to achieve our goals, that is, the means by which policies are implemented. So a policy might be: "wealth inequality should be bounded", and mechanisms to achieve it might include "progressive income tax", "subsidies for the poor", or "universal basic income". Given a policy, science and rationality are certainly applicable to designing and evaluating the efficacy of mechanisms to achieve the policy.
Our biggest problem is that most of our political discourse is consumed with debating what we call policies, but which are usually mechanisms to achieve some policy. The policy is seldom explicitly stated and almost never debated, while the participants in a typical political debate take it for granted that everyone accepts whatever implicit policy their proposed mechanism seeks to achieve. But even worse, we implement mechanisms without ever tying them to an explicit policy goal, which makes it difficult to determine whether a given mechanism is working. Politically you get a situation where anyone who questions a mechanism is assumed to be disagreeing with the unstated policy behind the mechanism. The result is that bad mechanisms become entrenched, and are no longer subject to rational or scientific examination. And that just sucks.
If I could interject one question into every political debate, it would be: what are you trying to achieve? And if I could have a second question it would be: how will you know if you've achieved it?
I had an excellent mentor at NASA at age 16. Learned about high-level languages and algorithms using the CAL language on Tymshare. Learned about how computers actually work by toggling in programs through console switches on a PDP-5. Learned how to code efficiently mostly by reading other people's code. Learned FORTRAN IV from McCracken's book. Read a lot of computer manuals, back when computers came with full documentation sets.
Still working as a developer at age 63, and still love programming. These days I mostly use Scala and Python, and when I must, JavaScript. In my spare time I pursue my passion, which is machine learning, taking online classes and working on Kaggle competitions.
Not just a single disaster. Just as we've seen more frequent and more powerful storms in recent years, so too I expect there will be more frequent and more powerful earthquakes, including the possibility of tsunamis. More and larger volcanic eruptions would not surprise me. I expect most of the action would be around the boundary of the Pacific plate. But things could get interesting on the mid-Atlantic ridge as well.
The consequences of this on civilization would be fairly devastating. Besides lives lost in individual incidents, there could be hundreds of millions of refugees. Economic collapse would surely follow, straining our political and social institutions to the breaking point. Much of the infrastructure which supports our technology also would be severely impacted. Major ports may be destroyed by tsunamis or earthquakes, disrupting supply chains for food, and causing food shortages, even assuming that food production itself remains intact. Ultimately a sizable chunk of the human population will perish. But unless Earth goes the way of Mars or Venus, humanity will survive and over time, adapt.
It's useless to debate whether this is a natural cycle or a result of human activity. It would be great if we could limit our carbon emissions, but I fear we're already two or three decades too late. What matters now is trying to understand what is happening, anticipate the possible consequences, and prepare. What we need is something like the International Geophysical Year, except that intensive level of research needs to be sustained for at least a decade.
The article says it's nothing to worry about. Well that's what they said to Jor-El, and you know how that turned out.
The shift in mass distribution caused by melting ice will cross the boundaries of tectonic plates, changing the relative pressure on adjacent plates. This will likely lead to increased earthquake and volcanic activity. On the bright side, the ash from the volcanoes may limit global warming (maybe even trigger an ice age), and deformations of the sea floor may reduce sea level rise (or make it worse). Another possible impact is the triggering of a geomagnetic reversal.
The political debates about climate change are futile. What we should be discussing is whether we know enough about how this planet works (and have the technology) to attempt some kind of active intervention, such as carbon sequestration or actually blocking sunlight from space. But we'll probably just end up fighting over whatever habitable parts of the planet remain. Maybe the survivors will be wiser.
They dont really give a shit about the data in this case, they want to cow the tech sector into not making their jobs harder.
Maybe they care about the data, but it's likely they have other ways to brute force the passcode. This battle with the tech sector over encryption has been ongoing for more than a decade. What's different about this case is that it is the best opportunity the government has had to use fear of more mass killing to shut down the thinking part of the average person's brain. Their goal is to ensure that they have the keys to decrypt anything encrypted by the general public. (Anybody remember key escrow?)
Anyone with a basic technical understanding of how encryption works knows that there is no way to stop a knowledgeable person from implementing encryption in software, and keeping their keys private. So this is really about preventing the average person who lacks that knowledge from having unbreakable encryption. It's interesting that the situation with the general public and firearms is a similar situation, and in fact cryptography was once classified as a munition. It seems to me that a liberal interpretation of the Second Amendment might apply to encryption. I point that out especially for those of you who feel entitled to assault weapons under the Second Amendment.
Personally, I think we need to look at personal devices, and perhaps even our use of search engines, as extensions of our minds and as such, should be treated by the law with the utmost concern for privacy. After all, the technology to actually read minds is advancing, and the day may come when the precedents we set today for our personal devices are applied to our brains.
Just imagine, there could be a phone app that displays an arrow to show the user which way to walk. Using the Lidar to detect obstacles, the app could enable a phone zombie to become almost self-driving, avoiding obstacles and other people. Almost like a real person.
With self-driving cars I expect parking will become like having valet parking everywhere. Think of how guests arrive and leave at a large hotel. There will need to be a reasonable sized area where cars can come and stop to pick up and drop off passengers and their stuff. Once empty, the cars will go and park themselves in high-density fashion. Your typical Safeway parking lot will need to be reorganized to accommodate this.
There will be an opportunity to reduce the space allotted to parking at many places.
I first learned machine language on a PDP-5, which was similar to the PDP-8, but limited to 4KB of memory. Mostly I just used it to toggle in small programs through the console switches, but I think we got the FOCAL interpreter running on it at one point. Those were the days. To think now there is a generation of programmers who have known nothing but JavaScript.
Of course vulnerabilities remain. But when you're deliberately aiming for a secure *system*, they're a lot less impactful. Kinda like how turning ASLR on simply nullifies entire classes of vulnerabilities. MULTICS, according to your paper, didn't have problems with buffer overflows. Thirty years ago, this was a solved problem. Why is it an ongoing problem now?
Because programming languages like C/C++ are still in wide use. I suppose most people who still use these languages would tell you that they must, for reasons of efficiency. Then they would start talking about how their application can't tolerate pauses for garbage collection. But of course you could have a language which supports manual allocation of data types, with a maximum length that is enforced at runtime.
I've addressed why I think software engineering hasn't progressed more in a previous post. The argument I make there about hobbyists designing languages and lack of industry support for standardization also apply to software security. But the problem of security is open-ended. We could have better languages which prevent all kinds of abuses of the hardware-level machine model, languages in which buffer overflows and stack overflow exploits are impossible. But then someone writes a program that builds a SQL query in a string, but doesn't take the necessary precautions, and you have SQL injection. Now the SQL interpreter is in some sense another level of virtual machine which needs to be protected from abuse. It's not hard to do that if your program creates SQL queries using a data structure that supports a higher level of abstraction than strings. But if a SQL client library is provided, and it takes a SQL query as a string, building a safer level of abstraction on top of that probably isn't going to occur to most programmers. Nor will they necessarily take the time to discover that someone else has implemented a higher-level interface. Strings are what they know, and strings are what they'll use.
Likewise, when JavaScript was added to the browser, it created a whole new world of potential security vulnerabilities. Brendan Eich may not have been a hobbyist in the strictest sense, since he was being paid. But he was working under a very tight schedule which prioritized functionality over security. And I suspect even he would admit to having made a number of rookie mistakes in language design. More importantly though, is that some kind of client-side scripting of HTML was virtually inevitable. There is an inexorable force toward adding more functionality to successful software. And whenever new abstractions are created, or new interpreters built, there is the potential for new kinds of security vulnerabilities which can exist regardless of how secure the underlying infrastructure may be.
This is not to say that I believe secure software is impossible. But it is a moving target that can't be addressed simply by instilling in programmers a comprehensive list of secure programming DOs and DON'Ts. Programmers really need to be able to recognize when their code may be creating new kinds of security vulnerabilities.
MULTICS eh? Here's an interesting paper looking back on MULTICS security:
Thirty Years Later: Lessons from the Multics Security Evaluation
In spite of the fact that security was a top priority for MULTICS, in spite of the fact that it was written in PL/I rather than C, in spite of the fact that it was a very small, less complex system by today's standards, in spite of the fact that it was more secure than most modern systems, MULTICS was easily penetrated during the security evaluation. So I maintain my original position that writing secure software is hard. So hard that even when people are diligently trying to write secure software, vulnerabilities remain.
MIT's ITS was another system derived from MULTICS, and deliberately insecure. It even had a non-privileged "crash" command to crash the system, and logins were optional.