No. There's no fundamental human right to live in San Francisco. It would be a problem if people weren't allowed to leave San Francisco, but that is not the problem in this case.
My heart goes out to those evicted, or fearing eviction. To my untrained eye, the problems seem like an obvious result of supply-and-demand. SF has limited land, hasn't built much in the way of housing for a long time, and is in high demand. Of course the housing prices will go way up. The only solutions are to make it less desirable (lower demand), or increase housing (increase supply). Here's an interesting article: https://medium.com/@Scott_Wien...
Other cities have done this, e.g., DC has aggressively added new units.
There's no need for a formal legal letter developed by a lawyer. This is straightforward.
Send an email to your boss and say, "May I please release these code improvements to this open source software under their respective licenses?" If he says yes, then keep the email - and perhaps better, post it publicly somewhere.
Your boss can change his mind, but that doesn't change anything. If you buy a car, and a year later say "hey, I've changed my mind", you don't suddenly get your money back. As long as there's no initial deceptions, or something illegal about an agreement, then agreements stay that way.
If he says no, well, that's that. Sometimes organizations to silly things, but it's their legal right to do silly things.
Caveat: I'm not a lawyer. But I don't see why this needs to be complicated.
Poster just means that Wayland support is perfect, I think.
In any case, GNOME 3 has gotten better. I tweak it, and yes I wish that wasn't needed for pleasant use, but once tweaks are added GNOME works reasonably well.
I think a key part is simple: good story quality. Key steps:
Eliminate duplicates. The submission system should quickly warn of potentially duplicate URLs or subject words.
Quick review. Find a way to have a quick review of the story summary before posting. You don't want to slow down the flow too much, but it'd be good to have someone check for missing "not"s, URLs that don't work, and so on. I would assume you already have a spelling and grammar checker, but it's not clear it's always working. That sort of basic for a few sentences really shouldn't take that long.
Try to find good topics. That one in some sense is the hardest.
The discussions are sometimes interesting - and sometimes not. But I think if the stories start higher-quality, the follow-up discussion is more likely to be better.
In the longer term, the system for entering text is... quirky. Has someone considered using Markdown? Yeah, Markdown processors vary, but lots of people know Markdown (e.g., via GitHub), and specs like CommonMark and libraries like Red Carpet make it fairly painless.
The point of the article How are students learning programming in a post-Basic world? isn't that we should all use Basic. The point is that there's a need for a single 'starter' language so that people who have no experience can get started using something. That language should come with practically all computers, should be portable enough so that you can write programs that port to many computers, should be immediately accessible so beginners can quickly learn some basics, and should be useful enough so that beginners can create useful programs.
There are a number of reasonable contenders, including Python, Ruby, and Java. A version of Ruby comes with MacOS, but none of these 'just comes' with the computer regardless of what OS you run - so in most cases, before you even get started, you have to explain how to download and install something. Not ideal. Java is what a lot of people use professionally, but it does take more time to get started when you know nothing. Python has many advantages for simplicity, but you need to install it in many cases.
Perhaps the dark horse here is Javascript ES6. Javascript is available almost everywhere, and people can get started quickly. As a first language Javascript's unusual approach to OO programming (with prototyping) has probably held it back, but ES6 adds standard class notation, and that might make it much easier to use as a starter language.
I looked at the list, and it's really no big deal. Firefox will just add support for some aliases for standard names, so that existing websites that use "-webkit" prefixes will "just work" today. That's good for users, and it doesn't mean the 'death of standards' or anything like that. It's reasonable to ask people to use the standard names going *forward*. However, it takes a long time for older sites to update, and they rarely update completely correctly. This decision means that Firefox users will have a good experience looking at other sites.
Italy believes Apple was supposed to pay €880m in tax between 2008 and 2013, and Apple only had to pay €318m instead. If this report is accurate, Apple's tax evasion appears to have been handsomely rewarded.
Perhaps Italy's estimate of taxes owed turned out to be wrong. Maybe. However, I suspect the tax authorities simply decided it was easier for them personally to just settle. The problem is that this creates a terrible precedent... and also robs their citizens of the services those taxes were supposed to fund. I'm no fan of big taxes, but each country gets to decide what taxes and services are appropriate. Other companies have now been told that it would be foolish to pay their taxes.
If countries want to prevent tax evasion, they need to actually acquire all the back taxes owed, along with stiff penalties to discourage recurrence.
There is a moon that orbits the Earth that English speakers normally just call "the Moon" (note the capital letter for a proper noun). That doesn't mean there aren't other moons (obviously). If we need to give it a name, I'd suggest the Latin name (Luna), but most people don't use that terminology.
Similarly, we are in "the Solar System", but I don't see a problem calling other systems "solar systems"; they just aren't THE solar system.
Good. 8 more years of time working correctly. The fundamental issue is that the Earth just doesn't care what our atomic clocks measure. If programmers want an exact time system without leap seconds, use TAI, that's what it's for. Most people in the world don't care if it's hard to code leap seconds. Instead, most people go outside occasionally, and they expect that 'noon' means approximately 'sun at highest point'. We can switch to some system other than leap seconds, but if we expect 'noon' to have its conventional meaning, then we need to agree on a system that does that.
This makes the most sense of all the proposals I've seen. How can we help encourage the FCC to consider this? Is there an email address at the FCC for taking comments (e.g., to encourage it)? I'd like to send a "me too" so that the FCC knows to consider this proposal carefully.
If you're worried about compromised CPUs being used to compile executables that are used by others, then reproduceable builds are a great countermeasure. Just use reproduceable builds on many different CPUs, and compare them to ensure they are the same (for a given version of source and tools). The more variations, the less likely that there is a subversion. If what you're compiling is itself a compiler, then use diverse double-compiling (DDC) on many CPUs.
If you're worried that an INDIVIDUAL may end up with a compromised CPU, then yes, it's much harder to counter attack. On some systems, you can isolate the system (no network traffic, etc.). That said, an adversary has to send packets to subvert a specific system, then every time they do the subversion they risk being detected, so it's far less likely to be used for bulk surveillance... it would more likely be one well-resourced organization (e.g., a government) working against another well-resourced organization.
If scholar just means "one who studies", then obviously anyone who studies a religious text for a long time BECAUSE they're a believer is by definition a scholar. I don't think that's what you mean.
If we change "scholar" to "scientist", it's quite clear that scientist is not synonymous with atheist. Pew research found that "just over half of scientists (51%) believe in some form of deity or higher power; specifically, 33% of scientists say they believe in God, while 18% believe in a universal spirit or higher power". Besides, many would say that science requires repeatable experiments, and many truths simply aren't repeatable (e.g., history).
Most scholars don't think that the Talpiot Tomb has anything to do with Jesus. For exampel, Géza Vermes says the arguments for the Talpiot tomb are not "just unconvincing but insignificant" (see the Wikipedia page). Also, Christian theology does not depend on whether or not the shroud of Turin is real.
I'm not muslim, but even the summary notes a perfectly reasonable explanation - the parchment could be an old one. And frankly, I'm skeptical that the carbon dating is that precise; carbon dating depends on a lot of assumptions that can easily be false in specific circumstances. (Yes, radioactivity decreases at a fixed rate... but you have to make BIG assumptions about its starting value.) So while this article makes for a good headline, the current actual evidence is rather worthless.
I've been googling around and can't find any evidence that it's blocked or mitigated. I know it *was* vulnerable, and can find no evidence to the contrary, so I have to presume it's still vulnerable. Blech.
What about the disastrous SwiftKey vulnerability? It makes Samsung Android systems vulnerable too. Samsung said they'd fix it back in June, but we still have no patch.
When buying an Android phone: Measure how many days it takes from the vulnerability report (at least publicly) until it's patched in phones already used by customers. Focus on phones more than 2 years old, since your phone will be that age someday. Then: Don't buy from unresponsive makers. I suspect that if a few buying guides included those numbers, some manufacturers and service providers would start paying attention.
"How would an experienced developer get these problems in the first place?"
A lot of projects do not follow widely-accepted best practices... even if they are experienced... and that is a problem!
A remarkable number of OSS projects fail to have a public source control system (#2). That includes many established projects that everyone depends on. Actually, a number of OSS projects - and projects that people THINK are OSS but are not (because they have no license) - fail many of these points. It's not that Red Hat's internal processes are immature; Tom was trying to bring in software from someone else (Google in this case) and was fed up by the poor practices from people who should know better.
Yes, #7 refers to a best practice (let people pick their install directory) that's been around for at least 20 years and probably much longer, but it's still widely NOT followed.
Anyway, that's Tom's point; there are a lot of widely-accepted best practices that are NOT followed, and that needs to change.
If you don't like this idea, send an email (as they request) to Sharron Cook, publiccomments@bis.doc.gov. Please refer to RIN 0694-AG49 in all comments and in the subject line of email comments. Explain why you think it's a bad idea, with reasoned arguments.
Before commenting, you should read the proposal first:
https://www.federalregister.go...
Put away the bingo card. Some languages, like Lisp and Haskell, actually DO bring seriously different ideas to the table, and there are tasks where their ideas are useful. A few examples may help. Once a "variable" is set, you cannot change its value (though it CAN go out of scope). This has serious reasoning and optimization advantages, but it requires a different way of thinking. Haskell has lazy evaluation, i.e., it computes nothing until you ask for it. It's routine to define infinitely-large data structures, which is a non-problem because only the parts you need are calculated. If you're only familiar with the ALGOL language family (C, C++, Objective-C, Java, C#, PHP, Python, etc.), you'll need to do some real learning.
My article How to Prevent the next Heartbleed lists in detail different ways that Heartbleed could have been found ahead-of-time. The point isn't to find it now, it's to learn from Heartbleed so we prevent a recurrence. There are many ways to detect vulnerabilities like this ahead of time... we need to start using some of them.
At one time a number of constructed languages were created and got some speakers (including Esperanto). But relatively few people learn a language just for fun (yes, I know about Klingon and Elvish, but they will not be replacing English). Most people will only learn a language if they have a strong need to USE that language to communicate with some large group of people.
Esperanto is actually much easier to learn than English; it's a reasonable constructed language. I spent a little time learning some of it, and I appreciate its clever approaches to making it easier to learn (e.g., the "mal-" prefix). The problem is that you can only speak with other Esperanto speakers in it.
English is a mess of complications, like all natural languages. In some ways English is easier; in others it is harder. But when you learn English, you can talk to the other 1 billion people who can speak English as a first or second language. For most people, THAT is what makes English worth learning. Again, you normally learn a language specifically so you can communicate with others.
Chinese actually has more speakers than English, but they are concentrated in China; worldwide, it's easier to find an English speaker than any other specific language.
If you want an easier-to-learn language than standard English, you might consider an English-based controlled language like "Basic English" https://en.wikipedia.org/wiki/... or the "Special English" used by Voice of America https://en.wikipedia.org/wiki/... ; these are more complicated than Esperanto, but you can talk with many more speakers. I can imagine "mostly compatible with existing English" could be a necessary criteria for "new" constructed language, if you need to create one at all.
Slashdot Mirror
No. There's no fundamental human right to live in San Francisco. It would be a problem if people weren't allowed to leave San Francisco, but that is not the problem in this case.
My heart goes out to those evicted, or fearing eviction. To my untrained eye, the problems seem like an obvious result of supply-and-demand. SF has limited land, hasn't built much in the way of housing for a long time, and is in high demand. Of course the housing prices will go way up. The only solutions are to make it less desirable (lower demand), or increase housing (increase supply). Here's an interesting article: https://medium.com/@Scott_Wien...
Other cities have done this, e.g., DC has aggressively added new units.
There's no need for a formal legal letter developed by a lawyer. This is straightforward. Send an email to your boss and say, "May I please release these code improvements to this open source software under their respective licenses?" If he says yes, then keep the email - and perhaps better, post it publicly somewhere. Your boss can change his mind, but that doesn't change anything. If you buy a car, and a year later say "hey, I've changed my mind", you don't suddenly get your money back. As long as there's no initial deceptions, or something illegal about an agreement, then agreements stay that way. If he says no, well, that's that. Sometimes organizations to silly things, but it's their legal right to do silly things. Caveat: I'm not a lawyer. But I don't see why this needs to be complicated.
Poster just means that Wayland support is perfect, I think. In any case, GNOME 3 has gotten better. I tweak it, and yes I wish that wasn't needed for pleasant use, but once tweaks are added GNOME works reasonably well.
I think a key part is simple: good story quality. Key steps:
The discussions are sometimes interesting - and sometimes not. But I think if the stories start higher-quality, the follow-up discussion is more likely to be better.
In the longer term, the system for entering text is... quirky. Has someone considered using Markdown? Yeah, Markdown processors vary, but lots of people know Markdown (e.g., via GitHub), and specs like CommonMark and libraries like Red Carpet make it fairly painless.
Good luck!
I think "Planetary Defense Office" is a cool name. Someone should invite William Shatner.
The point of the article How are students learning programming in a post-Basic world? isn't that we should all use Basic. The point is that there's a need for a single 'starter' language so that people who have no experience can get started using something. That language should come with practically all computers, should be portable enough so that you can write programs that port to many computers, should be immediately accessible so beginners can quickly learn some basics, and should be useful enough so that beginners can create useful programs.
There are a number of reasonable contenders, including Python, Ruby, and Java. A version of Ruby comes with MacOS, but none of these 'just comes' with the computer regardless of what OS you run - so in most cases, before you even get started, you have to explain how to download and install something. Not ideal. Java is what a lot of people use professionally, but it does take more time to get started when you know nothing. Python has many advantages for simplicity, but you need to install it in many cases.
Perhaps the dark horse here is Javascript ES6. Javascript is available almost everywhere, and people can get started quickly. As a first language Javascript's unusual approach to OO programming (with prototyping) has probably held it back, but ES6 adds standard class notation, and that might make it much easier to use as a starter language.
I looked at the list, and it's really no big deal. Firefox will just add support for some aliases for standard names, so that existing websites that use "-webkit" prefixes will "just work" today. That's good for users, and it doesn't mean the 'death of standards' or anything like that. It's reasonable to ask people to use the standard names going *forward*. However, it takes a long time for older sites to update, and they rarely update completely correctly. This decision means that Firefox users will have a good experience looking at other sites.
Italy believes Apple was supposed to pay €880m in tax between 2008 and 2013, and Apple only had to pay €318m instead. If this report is accurate, Apple's tax evasion appears to have been handsomely rewarded. Perhaps Italy's estimate of taxes owed turned out to be wrong. Maybe. However, I suspect the tax authorities simply decided it was easier for them personally to just settle. The problem is that this creates a terrible precedent... and also robs their citizens of the services those taxes were supposed to fund. I'm no fan of big taxes, but each country gets to decide what taxes and services are appropriate. Other companies have now been told that it would be foolish to pay their taxes. If countries want to prevent tax evasion, they need to actually acquire all the back taxes owed, along with stiff penalties to discourage recurrence.
There is a moon that orbits the Earth that English speakers normally just call "the Moon" (note the capital letter for a proper noun). That doesn't mean there aren't other moons (obviously). If we need to give it a name, I'd suggest the Latin name (Luna), but most people don't use that terminology. Similarly, we are in "the Solar System", but I don't see a problem calling other systems "solar systems"; they just aren't THE solar system.
Good. 8 more years of time working correctly. The fundamental issue is that the Earth just doesn't care what our atomic clocks measure. If programmers want an exact time system without leap seconds, use TAI, that's what it's for. Most people in the world don't care if it's hard to code leap seconds. Instead, most people go outside occasionally, and they expect that 'noon' means approximately 'sun at highest point'. We can switch to some system other than leap seconds, but if we expect 'noon' to have its conventional meaning, then we need to agree on a system that does that.
This makes the most sense of all the proposals I've seen. How can we help encourage the FCC to consider this? Is there an email address at the FCC for taking comments (e.g., to encourage it)? I'd like to send a "me too" so that the FCC knows to consider this proposal carefully.
If you're worried about compromised CPUs being used to compile executables that are used by others, then reproduceable builds are a great countermeasure. Just use reproduceable builds on many different CPUs, and compare them to ensure they are the same (for a given version of source and tools). The more variations, the less likely that there is a subversion. If what you're compiling is itself a compiler, then use diverse double-compiling (DDC) on many CPUs.
If you're worried that an INDIVIDUAL may end up with a compromised CPU, then yes, it's much harder to counter attack. On some systems, you can isolate the system (no network traffic, etc.). That said, an adversary has to send packets to subvert a specific system, then every time they do the subversion they risk being detected, so it's far less likely to be used for bulk surveillance... it would more likely be one well-resourced organization (e.g., a government) working against another well-resourced organization.
If scholar just means "one who studies", then obviously anyone who studies a religious text for a long time BECAUSE they're a believer is by definition a scholar. I don't think that's what you mean.
If we change "scholar" to "scientist", it's quite clear that scientist is not synonymous with atheist. Pew research found that "just over half of scientists (51%) believe in some form of deity or higher power; specifically, 33% of scientists say they believe in God, while 18% believe in a universal spirit or higher power". Besides, many would say that science requires repeatable experiments, and many truths simply aren't repeatable (e.g., history).
Most scholars don't think that the Talpiot Tomb has anything to do with Jesus. For exampel, Géza Vermes says the arguments for the Talpiot tomb are not "just unconvincing but insignificant" (see the Wikipedia page). Also, Christian theology does not depend on whether or not the shroud of Turin is real.
I'm not muslim, but even the summary notes a perfectly reasonable explanation - the parchment could be an old one. And frankly, I'm skeptical that the carbon dating is that precise; carbon dating depends on a lot of assumptions that can easily be false in specific circumstances. (Yes, radioactivity decreases at a fixed rate... but you have to make BIG assumptions about its starting value.) So while this article makes for a good headline, the current actual evidence is rather worthless.
I've been googling around and can't find any evidence that it's blocked or mitigated. I know it *was* vulnerable, and can find no evidence to the contrary, so I have to presume it's still vulnerable. Blech.
What about the disastrous SwiftKey vulnerability? It makes Samsung Android systems vulnerable too. Samsung said they'd fix it back in June, but we still have no patch.
When buying an Android phone: Measure how many days it takes from the vulnerability report (at least publicly) until it's patched in phones already used by customers. Focus on phones more than 2 years old, since your phone will be that age someday. Then: Don't buy from unresponsive makers. I suspect that if a few buying guides included those numbers, some manufacturers and service providers would start paying attention.
"How would an experienced developer get these problems in the first place?"
A lot of projects do not follow widely-accepted best practices... even if they are experienced... and that is a problem!
A remarkable number of OSS projects fail to have a public source control system (#2). That includes many established projects that everyone depends on. Actually, a number of OSS projects - and projects that people THINK are OSS but are not (because they have no license) - fail many of these points. It's not that Red Hat's internal processes are immature; Tom was trying to bring in software from someone else (Google in this case) and was fed up by the poor practices from people who should know better.
Yes, #7 refers to a best practice (let people pick their install directory) that's been around for at least 20 years and probably much longer, but it's still widely NOT followed.
Anyway, that's Tom's point; there are a lot of widely-accepted best practices that are NOT followed, and that needs to change.
Obligatory comic here: http://owlturd.com/post/730466...
xkcd's "Significance" pithily explains p-hacking.
If you don't like this idea, send an email (as they request) to Sharron Cook, publiccomments@bis.doc.gov. Please refer to RIN 0694-AG49 in all comments and in the subject line of email comments. Explain why you think it's a bad idea, with reasoned arguments. Before commenting, you should read the proposal first: https://www.federalregister.go...
Don't even ask. On the initial start-up, start calculating those new keys. You want the DEFAULT to be secure.
Put away the bingo card. Some languages, like Lisp and Haskell, actually DO bring seriously different ideas to the table, and there are tasks where their ideas are useful. A few examples may help. Once a "variable" is set, you cannot change its value (though it CAN go out of scope). This has serious reasoning and optimization advantages, but it requires a different way of thinking. Haskell has lazy evaluation, i.e., it computes nothing until you ask for it. It's routine to define infinitely-large data structures, which is a non-problem because only the parts you need are calculated. If you're only familiar with the ALGOL language family (C, C++, Objective-C, Java, C#, PHP, Python, etc.), you'll need to do some real learning.
My article How to Prevent the next Heartbleed lists in detail different ways that Heartbleed could have been found ahead-of-time. The point isn't to find it now, it's to learn from Heartbleed so we prevent a recurrence. There are many ways to detect vulnerabilities like this ahead of time... we need to start using some of them.
At one time a number of constructed languages were created and got some speakers (including Esperanto). But relatively few people learn a language just for fun (yes, I know about Klingon and Elvish, but they will not be replacing English). Most people will only learn a language if they have a strong need to USE that language to communicate with some large group of people. Esperanto is actually much easier to learn than English; it's a reasonable constructed language. I spent a little time learning some of it, and I appreciate its clever approaches to making it easier to learn (e.g., the "mal-" prefix). The problem is that you can only speak with other Esperanto speakers in it. English is a mess of complications, like all natural languages. In some ways English is easier; in others it is harder. But when you learn English, you can talk to the other 1 billion people who can speak English as a first or second language. For most people, THAT is what makes English worth learning. Again, you normally learn a language specifically so you can communicate with others. Chinese actually has more speakers than English, but they are concentrated in China; worldwide, it's easier to find an English speaker than any other specific language. If you want an easier-to-learn language than standard English, you might consider an English-based controlled language like "Basic English" https://en.wikipedia.org/wiki/... or the "Special English" used by Voice of America https://en.wikipedia.org/wiki/... ; these are more complicated than Esperanto, but you can talk with many more speakers. I can imagine "mostly compatible with existing English" could be a necessary criteria for "new" constructed language, if you need to create one at all.