Why React Native won't work - <AUTHOR> http://rexstjohn.com/is-react-native-cross-platform-snake-oil/

<comment><USER2> It seems the entire blog post is based on a misunderstanding of React Native's goals.

I don't think the point of React Native has anything to do with building a common UI across different platforms. In fact, they admit you'll need to build the UI separately for each platform. They're basically just exposing native components for manipulation in a React-like way, so beyond having an opportunity to make the UI in a platform specific way, there's actually an obligation to do so.</comment>


Solving an Unsolvable Math Problem - <AUTHOR> http://www.snopes.com/college/homework/unsolvable.asp

<comment><USER2> George Dantzig also invented the Simplex algorithm.

</comment><comment><USER3> Any link to the problem he solved?

<comment><USER4> I think this is the second problem he solved (to which he was added later as the co-author). [http://projecteuclid.org/DPubS?service=UI&version=1.0...](http://projecteuclid.org/DPubS?service=UI&version=1.0&verb=Display&handle=euclid.aoms/1177729695)

Still searching for the first one...</comment></comment>


Apple's Retail Store Gameplan for the iPhone 6 Launch - <AUTHOR> http://9to5mac.com/2014/09/16/exclusive-this-is-apples-retail-store-gameplan-for-iphone-6plus-launch/

<comment><AUTHOR> Customer journey gameplans. It's fascinating how much attention Apple pays to retail details.</comment>


US bankrolled anti-Morsi activists - <AUTHOR> http://www.aljazeera.com/indepth/features/2013/07/2013710113522489801.html

<comment><AUTHOR> _It is Saudi-backed military coup in Egypt, Obama just dragging his heels over it_ [http://rt.com/op-edge/military-coup-egypt-saudi-889/](http://rt.com/op- edge/military-coup-egypt-saudi-889/)</comment>


Web hosting a downward trend? - <AUTHOR> http://royal.pingdom.com/?p=312 <comment><USER2> Google trends is deceiving. I can only assume that the values shown are a fraction of the total number of searches -- according to Google trends, "linux" and "windows" have declined significantly in the past 4 years, while "firefox" has stayed relatively constant since late 2004 aside from spikes when releases occurred.

If I'm right about the plotted values being fractions of the total number of queries, the apparent decline in "web hosting" is probably just an artifact of the internet continuing to expand from the computer-literate to the computer- illiterate: Those of us who would have any reason to care about web hosting are simply being outnumbered.

<comment><AUTHOR> What puzzles me is that on one hand in the last 5 years or so most of these search phrases have been on a downward trend, while Google Search popularity and global penetration has increased over the same duration. Shouldn't nearly every search phrase show an upward trend, due to the increase in search users?

<comment><USER2> _Shouldn't nearly every search phrase show an upward trend, due to the increase in search users?_

That was my point -- I'm guessing that Google is normalizing these values by dividing by the total number of searches. So if searches for "web hosting" went from 1 million to 2 million, but those number are 0.002% and 0.001% of the total number of searches respectively, the graph would show a decline.</comment></comment></comment>


China Sentences Ex-Chairman of Hengfeng Bank to Death - <AUTHOR> https://www.bloomberg.com/news/articles/2019-12-27/china-sentences-ex-chairman-of-troubled-hengfeng-bank-to-death <comment><USER2> Is China's financal system / regulatory system transparent enough to really know what happened here?</comment>


Coronavirus Cases Strain New York City Hospitals - <AUTHOR> https://www.wsj.com/articles/coronavirus-cases-strain-new-york-city-hospitals-were-getting-pounded-11584719908 <comment><USER2> I am pretty nervous about sticking this out in the city but feel it's my least bad option right now. It sounds like Wuhan cases peaked 1-mo after draconian shelter-in-place measures were installed.[0]

There is no evidence our quarantine will be as aggressive and I fear it will be inadequate. Public transportation is still running. We're already at ~4000 cases.[1] Domestic cases are doubling every two days.[2]

Does anybody have some optimism about the situation here in NYC?

[0] [https://www.ibtimes.com/italy-coronavirus-lockdown-not- enoug...](https://www.ibtimes.com/italy-coronavirus-lockdown-not-enough-says- china-healthcare-staff-stop-counting-2943402)

[1] [https://www.nytimes.com/2020/03/20/nyregion/coronavirus- nyc....](https://www.nytimes.com/2020/03/20/nyregion/coronavirus-nyc.html)

[2] [https://twitter.com/sama/status/1241035936911130624?s=20](https://twitter.com/sama/status/1241035936911130624?s=20)

<comment><USER3> Presumptive patients with mild symptoms have to be separated from the healthy population by moving them into quarantine hotels or yellow-zone makeshift hospitals. Or you will still see family transmissions.</comment></comment>


MySQL client allows MySQL server to request any local file - <AUTHOR> https://gwillem.gitlab.io/2019/01/20/sites-hacked-via-mysql-protocal-flaw/ <comment><USER2> The intended usage is that the client tells the server, " _I want to load data from a file /path/to/data.txt on my local filesystem_" in a SQL command. As part of the protocol for executing the query the server sends a message to the client to request the contents of /path/to/data.txt. Unfortunately client's don't validate the file request and will send _any_ file (ex: /path/to/secrets.txt) even if there was no legit data request in their command.

This has been an issue with MySQL client drivers for years. I found and fixed the same issue in MariaDB Connector/J (JDBC driver (wire compatible with MySQL databases) in 2015. It rejects LOCAL DATA requests from the server unless the client app preregistered an InputStream (Java interface for generic stream of bytes) as data for the command being executing.

This is one of the many _many_ reasons I love open source database drivers. I was able to find and fix this issue only because I could see the source code. Similar "features" in proprietary databases could go unnoticed for years and even when discovered may not have feature flags to disable them.

<comment><USER3> It's strange to blame the client, while it's actually the fault of the server. A DB server should not be able to pipe an arbitrary file to the client.

<comment><USER4> You've got it backwards - the DB server can pipe an arbitrary file _from_ the client. So it is considered the fault of the client - it should not allow that. Since the mysql client is the one receiving the request and it should apply standard security practices by not blindly trusting an incoming request and instead validating that the path is equal to an earlier client load request sent to the server. (Although a better approach IMO would be to modify the wire protocol so the server "request" does not use the file name, but instead uses an ID from the earlier client request)

</comment></comment></comment><comment><USER5> Am I understanding this correctly: LOAD DATA LOCAL is used to bulk load datasets (like CSV files) into a MySQL database from the client. Why is the file transfer initiated by the server, and not by the client? Is it because they wanted to cover cases where the server processes / simplifies the query, and after processing, it becomes evident that the file is not needed at all? If so, why isn't there an additional check on the client that the file requested by the server matches a file that was previously used in a LOAD DATA LOCAL query? Is it because there is no query processing / parsing on the client side at all (in case of string SQL queries)?

<comment><USER6> The client does not parse the SQL prior to sending it to the server. The name of the file may actually be a computation result that depends on data in tables IIRC.

<comment><USER7> The docs say that it must be a literal:

> _The file name must be given as a literal string._

(From [https://dev.mysql.com/doc/refman/8.0/en/load- data.html](https://dev.mysql.com/doc/refman/8.0/en/load-data.html) )

However, you raise an interesting point about parsing. It is reasonable to want the server to do the parsing. You could, for example, tweak the grammar to add a new feature and do it entirely in an server update without needing to deploy a new client binary to every user. But then that makes it a bit harder to fix bugs like this.

There are surely some commands parsed and implemented by the client, though. Like connect, quit, and source for example. So another way to have designed this would be to make a local command to designate a file that the server will be allowed to access. You could define the path name on the client side and pass a symbolic reference to the server. Then the client could parse that command without taking on the burden of parsing SQL, and the client could still own opening files rather than taking orders from the server.

</comment></comment></comment><comment><USER8> But only with a modified MySQL server.

<comment><USER9> Yeah, i definitely think common workflow rarely involves connecting to untrusted servers. But... If server gets hacked, connecting in to see why your site is down could steal files before you know what happened. Even better if hack isn't visibly causing problems. Though that seems really indirect and unproductive an attack vector.

But sounds great for a honeypot. Put up an easy-to-hack WordPress server, and when attacker connects to mysql, start downloading all the PII files you can think of from the client.

<comment><USER10> What is it with this concept of "(un)trusted servers" that people throw around here all the time that seems to build on the assumption that the world consists only of entities that are to be distrusted and those that should have full access to and control over all your information and resources?

No, just because I don't expect my client to kill me, does not mean that therefore there is no reason to be concerned about a rogue employee of theirs being able to gain access to any other of my clients' servers that I have access to by patching an exploit into their MySQL server.

Nor is it reasonable to assume that everyone is on top of their IT security and their infrastructure is only under their own control, and that includes your own organization once it grows beyond one or two people.

If that is the kind of mental model you are working with, your IT security probably is shit. Even the slightest external vulnerability anywhere in your systems or the systems of people whose systems you access/(co-)manage is going to grant an attacker total control over your organization if that is how you manage security.

</comment></comment></comment><comment><USER11> by default, LOAD DATA LOCAL INFILE in libmysql is disabled by default to avoid such problem

</comment><comment><USER12> This is an issue that something like openbsd's pledge can prevent. No reason for the MySQL client to be able to read arbitrary files on the system.

[https://man.openbsd.org/pledge](https://man.openbsd.org/pledge)

<comment><USER13> This is incredibly off-topic, but can I use pledge as a sandbox by pledging and then execve-ing?

<comment><USER14> if you pass the `execpromises` parameter, and make sure that the flags DO NOT include the ability to further execve() (the `exec` flag), then yes, but openbsd pledge flags are not implicitly inherited like linux seccomp filters.</comment></comment></comment>


Facebook employees walk out in protest of Donald Trump's posts - tech-historian https://www.theverge.com/2020/6/1/21277135/facebook-walkout-protest-virtual-president-donald-trump-posts <comment><AUTHOR> If, like me, you're trying to parse this terrible headline and wondering when Trump started posting on Facebook, he doesn't. It's a reference to Twitter, which Facebook owns.

Never ascribe to fake news what can be explained by sloppy journalism.

<comment><USER2> Facebook owns Twitter?

<comment><AUTHOR> Dammit, apparently not. Apparently FB tried to buy it but failed.

So, now I _really_ don't understand the headline.

<comment><USER3> president presenting inflammatory misinformation on his Twitter. Twitter put warning on tweet. zuck defend president. people mad. people should be mad since, you know police seem to kill them for being brown skinned.

<comment><AUTHOR> That seems like common knowledge, but I suspect that actual veracity depends on who counts as brown-skinned. (And rather than split that hare, I wish we could work more on universal uplift.)</comment></comment></comment></comment></comment>


Fire and Motion - <AUTHOR> https://www.joelonsoftware.com/2002/01/06/fire-and-motion/ <comment><AUTHOR> ...but the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can't spend writing new features.

Look closely at the software landscape. The companies that do well are the ones who rely least on big companies and don't have to spend all their cycles catching up and reimplementing and fixing bugs...

The companies who stumble are the ones who spend too much time reading tea leaves to figure out the future direction of Cool Company Inc. People get worried about shiny.js and decide to rewrite their whole architecture for shiny.js because they think they have to. They are shooting at you, and it's just cover fire so that they can move forward and you can't...</comment>


Objective-C ARC best practices revisited - <AUTHOR> http://www.idryman.org/blog/2012/11/22/arc-best-practices-and-pitfalls/

<comment><USER2> Nice article, iOS developer must read</comment>


Elon Musk: "Anyone relying on Lidar is doomed." Experts: Maybe not - <AUTHOR> https://arstechnica.com/?p=1523325 <comment><USER2> The article didn't seem to go into regulatory issues at all. I'm not qualified to speak to the technical merits of LIDAR versus computer vision systems. But coming from a business planning background, and considering the fact that global rules surrounding LIDAR's use in consumer products can be charitably called "a patchwork", it seems to me that computer vision systems would be far easier to implement in a product designed for global export than LIDAR systems.

</comment><comment> matt-attack I actually agree and have been saying this for years. Cars need to model as much as possible on the way humans drive. No one will expect an autonomous car to be able to do things that an alert and expert driver can achieve. The entire road system is built around the premise that it can be navigated using vision alone, with no a priori knowledge of its layout.

You can drop me onto a roadway undergoing construction with temporary lanes that are diverted to the left side of the road, all in a suburb of Boston, a city I've never been to, at night in a rain storm. You and I can safely drive in this condition if alert and focused, while relying only on vision.

My premise is that any system that requires anything else, e.g. map data, lane boundary data, lidar, is doomed to fail in these edge case scenarios.

</comment><comment><USER3> Clickbaiting headline. Hotz and Levandowski are also experts and they agree with Musk. More truthful headline: Some experts say, but then again other experts say.

<comment><USER4> Hotz isn't an expert, he's a loudmouth tinkerer who never produced anything working before NHTSA shut him down. I've never heard Levandowski comment on the long-term necessity of lidar, but actions speak louder than words: Otto/Uber definitely used lidar (actually, the entire lawsuit with Waymo was over their lidar tech. Why would Levandowski have risked everything stealing it if he didn't think it was necessary?)

Elon really is alone in claiming that lidar isn't needed for self-driving.

<comment><USER3> You seem very angry for some reason that I do not understand. Your emotional response is not backed up by facts.

Hotz can certainly be considered an expert as founder and president of commai.ai. Whether he is a loudmouth or not is less relevant.

The remark by Levandowski can be found here: [https://www.youtube.com/watch?v=fNgEG5rCav4](https://www.youtube.com/watch?v=fNgEG5rCav4)

Whether these guys are ethical etc. is not of interest for this question.

> Elon really is alone in claiming that lidar isn't needed for self-driving.

No, precisely not.</comment></comment></comment>


Read-Eval-Print-λove – Forth Thinking - <AUTHOR> https://leanpub.com/readevalprintlove003/read <comment><USER2> Other Forth books resources:

Starting Forth : [http://www.forth.com/starting- forth/](http://www.forth.com/starting-forth/)

Thinking Forth : [https://sourceforge.net/projects/thinking- forth/files/](https://sourceforge.net/projects/thinking-forth/files/)

(Mirror) [http://www.dnd.utwente.nl/~tim/colorforth/Leo- Brodie/thinkin...](http://www.dnd.utwente.nl/~tim/colorforth/Leo- Brodie/thinking-forth.pdf)

These are provided by the author ([http://www.forth.com/forth/forth- books.html](http://www.forth.com/forth/forth-books.html)).

</comment><comment><USER3> For a less rosy view of forth, [http://yosefk.com/blog/my-history-with-forth- stack-machines....](http://yosefk.com/blog/my-history-with-forth-stack- machines.html) is a fascinating read.

</comment><comment><USER4> How does one deal with complex if-else statements in a concatenative language?

<comment><USER5> You usually just avoid them.

Some (e.g. Factor) do offer pattern matching/multimethods which are generally much cleaner.

<comment><USER4> I try to avoid them too, but sometimes business requirements are just too particular to do so.

<comment><USER6> It sure can be a problem when you have to deal with "business requirements" that you can't change, because in Forth you look for simplifications at every level.

Dealing with that may require to thing out of the box a bit, and forget about what is "good" and "bad" in other languages. Maybe you can use table-driven programming? Maybe you can do some dirty tricks with the return stack to get the control-flow you want? Maybe you really have to put that data in a variable? There's no single answer, and it can get ugly at times.

Not, BTW, ugly like in the article. This:

> : apply2 rot dup rot dip rot apply swap ;

... is an abomination. "dip" is questionable already. "rot", thought part of the standard, is best avoided. Because one should only deal with the top two elements of the stack. And of course "apply2" itself is suspicious.

Why the author showed this, even though he seems knowledgeable enough to know that he shouldn't? Because he picked a simplified Forth that did not let him use the return stack.

The author sure talks a lot about the "Forth philosophy" but apparently missed one or two things about it. If one wants to talk about philosophy, one should at least include in the bibliography what his inventor says about Forth ([http://www.ultratechnology.com/forth0.htm](http://www.ultratechnology.com/forth0.htm) \- a lot of stuff there, the main piece being 1xForth). I believe it's Moore that said something like "The important thing is not what you add, but what you remove". The return stack is a core component of Forth; picking a "simplified" Forth that won't let you use it ... well that language shouldn't be called Forth to begin with. That's a bad choice.

There are also other questionable choices like using [ ] for "quotations" when they are used for something totally different in standard Forth. Introducing "quotations" is also questionable in itself. It only looks easily implemented because Ruby provides all the memory management; but in reality implementing an interpreter on top of an interpreter is not viable (that makes like at least a x1000 slowdown relative to C); Forth interpreters are typically written in low level compiled languages (typically C), which don't provide garbage collection. And in the end, those "quotations" only look cute. What really helps is currying.

Forth is ugly, stupid and mean. It's up to you to find clever ways to write nice-looking programs.

</comment></comment></comment></comment><comment><USER7> Nice reading. Love the style. There was a typo (wok-flow) that I stared at a bit to make sure it wasn't intentional, though. :)

</comment><comment><USER8> Can someone explain to me why Forth is such a cult favorite? Is it because of it's age? I am curious. Is it worth learning?

</comment><comment><USER9> When was this released ?

<comment><USER10> ~12 hours ago according to [https://twitter.com/fogus/status/714545233090973696](https://twitter.com/fogus/status/714545233090973696)

<comment><USER9> doh... I need to sleep.

</comment></comment></comment><comment><USER11> It's funny how the guy assumes the reader must know Clojure

<comment><USER12> The publication is mainly about Lisps, and is written by Michael Fogus, a core contributor to Clojure/Clojurescript, and author of a couple books on Clojure.

I think that his intended readership is expected to be more familiar with Clojure than with Ruby.

</comment></comment><comment><USER13> Nice. But a font where the digit 2 (two) looks like the capital Z (last alphabet letter) isn't really usable. I quit reading after the Clojure example.

<comment><USER11> I suspect 99% of the readers stopped after the Clojure example.

<comment><USER14> Based on?</comment></comment></comment>


Rust Ownership Rules - <AUTHOR> https://www.geekabyte.io/2020/02/rust-ownership-rules.html <comment><USER2> I would argue that the phrase "One of Rust's main differentiator[s] is that it provides memory safety" should really be "One of Rust's main differentiators is that it provides memory safety without using a garbage collector". Which is the actual reason for needing (amongst others) ownership rules...

<comment><USER3> Rust doesn't provide memory safety in the GC sense — it can and will leak memory in ways Java wouldn't. Rather, it provides safety from all data races, which is something that conventional GCs don't give you.

<comment><USER4> How does java prevent memory leaks which rust couldn't ? Do you have examples for that? I was not aware that Java does it and am very interested in that.

<comment><USER5> One of the advantages of a tracing garbage collector is that it can recognize cycles. This means that if you have a few objects which point to each other, but the overall object graph is dead, a tracing GC should be able to collect these objects.

If you use reference counting in Rust, it will not be able to detect cycles. That said, it's not super easy to get a cycle accidentally.

<comment><USER4> Thank you. In hindsight, this was pretty obvious and I knew it already but I somehow didn't connect the pieces.

</comment></comment></comment></comment></comment><comment><USER6> I am a long time C++ user and have looked into Rust a bit but not used it in anger.

One thing not mentioned in the section about ownership move: unlike C++ where you can write arbitrary code in the move constructor, in Rust the footprint of the object is copied bitwise and there is no scope to customise this at all. If you have a class where this doesn't work (e.g. because it contains pointers into its own footprint) then you either need to refactor your class for Rust (e.g. change those pointers to offsets) or disable the move trait entirely and provide a utility function for move-like creation.

This is a trade off: as a class writer you get less flexibility, but as a class user you get much more predictable behaviour. And it's only possible because of the way that Rust just forgets about the original object (i.e. won't call its destructor at the point it would have done otherwise) at the language level. If it didn't, as in C++, you need some way to stop the original object freeing resources needed by the new object.

IMHO, move semantics and rvalue references in C++ are amongst the most confusing and worst designed parts of the language, so this is one of the most important benefits of Rust even before you get to the reference lifetime stuff.

<comment><USER7> > disable the move trait entirely and provide a utility function for move-like > creation.

There's no way to disable moving in general. But there is the Pin trait, which prevents you from moving certain types in certain cases, mostly to do with async/await.

<comment><USER8> The Pin type is a mess IMHO. It's the most C++-like corner of Rust. Its guarantees are shallow, so non-trivial uses are still unsafe. It ended up having complex interactions with other language features, creating a soundness hole. I'd rather bury it as a necessary evil that was required to ship async/await syntax, and nothing more.

<comment><USER9> I don't want to be defensive but this is completely off base, and very disheartening to see you post. Allowing users to write safe self-referential code was never a design goal of Pin - only to make it safe to manipulate self- referential objects generated by the compiler, which it has succeeded at. The incredibly overblown soundness hole had far more to do with the quirks of #[fundamental] than Pin (and the soundness hole is being resolved without changing the Pin APIs at all or breaking any user code).

The guarantees of Pin are now even being used beyond self-referential types but also for intrusive data structures in tokio's concurrency primitives. Pin is not for everyday users, but it is one of the greatest success stories of Rust's unsafe system. That you would call it a mess to a forum of non-users is quite disspiriting.

<comment><USER8> Sorry, I should have phrased that in a kinder way.

The fact that Pin is expected to enable more than it does is part of the problem. It's not for usual self-referential structs. It's not for usual umovable types. It has 2000 words of documentation, and I'm still not sure what to do with it. I need to understand pin/unpin, structural/non-structural projections, and drop guarantees. It has a lot of "you can do this, but then you can't do that" rules that the compiler can't help with.

For me most Rust features are either easy to understand (like UnsafeCell or MaybeUninit), or I can rely on the compiler make me use them correctly (like borrowing or generics). But with Pin my impression is that it pushes the limits of what can be done without compiler's safety net.

</comment></comment></comment></comment></comment><comment><USER10> I read somewhere that immutable and mutable borrows are perhaps alternatively understood as exclusive and shared borrows.

This means, if you have a &mut then you have an exclusive borrow. No other borrows are possible as long as your &mut lives (i. e. did not yet go out of scope). Usually this exclusive borrow is used for mutating values.

This dichotomy in terminology is shown when you learn about interior mutability. Here you can mutate values without having an exclusive borrow, an example is RefCell. The price you pay for this convenience is run-time checking of access. RefCell disallows mutation if some other location in your code already has asked for mutable access.

<comment><USER11> _I read somewhere that immutable and mutable borrows are perhaps alternatively understood as exclusive and shared borrows._

Yes, when it comes to exterior mutability, it's basically _single mutable xor multiple immutable_.

 _The price you pay for this convenience is run-time checking of access._

The nice thing is that _RefCell_ is not magic, it's Rust all the way down. E.g. the status of the borrow is updated by the destructors ( _Drop_ ) of the reference types. All administration is done using a signed integer to do reference counting. The value 0 means 'no borrows', any positive number indicates the number of immutable borrows, -1 means one mutable borrow.

It's well worth reading the implementation of _RefCell_ some time!

<comment><USER12> > The nice thing is that RefCell is not magic

I'd like to point out that `RefCell` does contain a bit of magic, since it is based on `UnsafeCell`, which is _the_ core "primitive" of Rust that enables interior mutability:

[https://doc.rust-lang.org/std/cell/struct.UnsafeCell.html](https://doc.rust- lang.org/std/cell/struct.UnsafeCell.html)

(Not trying to be pedantic, just to clarify things for less knowledgeable readers).

<comment><USER13> I assume the parent meant that there was no compiler magic at play, as far as I know UnsafeCell is written in pure Rust, just using unsafe code: [https://doc.rust-lang.org/src/core/cell.rs.html#1486-1488](https://doc.rust- lang.org/src/core/cell.rs.html#1486-1488)

So basically if Rust's stdlib didn't provide it, you could reimplement it yourself from scratch.

EDIT: actually, reading the comments, it looks like I'm wrong about that:

> If you have a reference `&SomeStruct`, then normally in Rust all fields of > `SomeStruct` are immutable. The compiler makes optimizations based on the > knowledge that `&T` is not mutably aliased or mutated, and that `&mut T` is > unique. `UnsafeCell<T>` is the only core language feature to work around the > restriction that `&T` may not be mutated.

<comment><USER12> I'm not sure that's correct. `UnsafeCell` is a Rust lang item that might disable some optimizations, I think?

[https://doc.rust-lang.org/src/core/cell.rs.html#1483](https://doc.rust- lang.org/src/core/cell.rs.html#1483)

<comment><USER13> You're right, I just saw that. Well I least I learned something new about Rust today!

</comment></comment></comment></comment></comment></comment><comment><USER14> What I like most about Rust is that I can pass references around without worrying whether the value they reference will continue to exist. This has been a constant mental burden for me in C++ and has led to some unnecessary defensive copying.

I'm not so sure whether Rust's strong immutability/exclusivity guarantees are worth the trouble though. Unexpected mutation hasn't been a major source of bugs or mental burden for me in other languages, at least not in a single threaded context.

<comment><USER15> Aren't the strong immutability/exclusivity guarantees specifically the reason you can pass around references without worrying if the referenced value will continue to exist?

<comment><USER14> I don't see a reason why that would be the case, but I remain open to be educated ...

<comment><USER16> Without the exclusivity, it would be easy for a reference to be invalidated; the classic example is

       let nut v: Vec<T> = ...;
       let r: &T = &v[0];

       v.push(...); // A

       foo(r); // B

The reference passed at B might be invalidated by A, if the vector is reallocated. It's the shared vs exclusive borrowing that defends against this, by flagging the above program as an error.

<comment><USER17> And this is another point in favor of compacting GCs: non-GC languages are moving things around almost as much (i.e. growable arrays are ubiquitous, plus hashmaps may be based on them too etc). Without a GC the simple task of moving references becomes dangerous and requires the pain demonstrated to us by Rust (or leads to pervasively crashy software culture demonstrated to us by C++). With GC, this type of thing is not something the developer needs to care about.

<comment><USER18> > pervasively crashy software culture demonstrated to us by C++

Please don't spread FUD. The majority of commercial C++ software out there is rock solid.

Vulnerabilities are the actual problem in today's Internet connected world and why Rust has grown so fast.

As for GCs: they are not good enough for some fields, so they cannot be used. Even state of the art ones like Go's.

<comment><USER19> The op is talking about compacting GCs and Go's isn't a compacting one.

Go's GC is a variation of a regular mark and sweep GC: the GC starts exploring the heap to find all reachable memory, and then clears the unreachable one, meanwhile compacting GCs move the reachable memory from one place (the "from space") to another (the "to space"), which become the new heap. Theses two garbage collectors famillies are completely different.

BTW, calling go's GC "state of the art" is debatable at best. See : [https://blog.plan99.net/modern-garbage- collection-911ef4f8bd...](https://blog.plan99.net/modern-garbage- collection-911ef4f8bd8e?gi=15496e3661e1)

<comment><USER18> And I was talking about GCs overall. The point was that Go's GC is pretty much the best GC out there used in major projects, designed to try to compete with systems programming languages and come as closely as possible to it. A lot of money has been put to make it as fast and deterministic as possible. It does not mean it is the latest in research, of course.

<comment><USER19> This is a real misunderstanding. Go's GC is not "pretty much the best GC out there" by most GC standards (it's already quite good and keeps getting better, though). And it hasn't been "designed to try to compete with systems programming languages".

Go as a language was designed like that, and special attention was made to allow as much value types as possible, to allocate as much things as you can on the stack, thus reducing GC pressure. For the first five years of Go or something, Go's GC was actually pretty bad (it was probably the most basic GC you could find in any somewhat popular language), but it wasn't too much of a deal because you can avoid it most of the time when it goes in your way (much more easily than in Java for instance).

After some time, they decided to enhance it, but they were on a budget (no lots of money spent on it" actually), so because in go you can avoid allocating memory on the heap, they decided to focus on GC latency instead of throughput (if the GC's throughput isn't good enough for you, you better reduce your allocations).

Overall go is a pretty fast language, and it's an engineering success, but it's _in spite_ of its GC and thanks to other parts of the language's design, not because Go's GC is exceptionally good (it's not, and if you read my link you'd understand how).

<comment><USER18> Thanks for the answer. I guess I have been misled, since Go proponents (including in HN) always argue the latest iteration sof their GC (which was discussed a few times here) had one of the lowest latencies of most production languages; and that is what made it suitable for many tasks.

Since I don't have a sense on the timescales, I will take your word for it that it was the reverse.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> I am just getting into rust myself - following from that 30 min article a few days ago.

From my understanding, the comments in a few of the examples are misleading. Author is stating things like "// mutable borrow occured" where there is no mutable borrow occuring. My understanding is that there is an implicit mutable borrow where the methods are being called (e.g. `original_owner.push('.');`) which is raising the errors

Can anyone with more experience confirm/deny that this is the case, as I want to be sure I am not misunderstanding this

<comment><USER20> You are correct. The type signature for push takes a mutable reference to self.

The code for a vector of i32s could look something like:

        impl Vec {
          pub fn push(&mut self, x:i32){
            // internal details
          }
        }

<comment><USER15> Many thanks. I think most of the confusion is to do with the comments, some of which the author has resolved so now my comment doesn't make much sense. But in the context of the original statement, thanks for your confirmation :)

</comment></comment></comment><comment><USER21> Lobster language offers interesting lightweight alternative to strict ownership model of Rust:

[http://aardappel.github.io/lobster/memory_management.html](http://aardappel.github.io/lobster/memory_management.html)

<comment><USER22> That solves ownership in terms of making sure the memory isn't deleted while something is owning it but, at least from my quick read, doesn't solve ownership issues related to concurrent access that Rust's ownership model does solve. Is that reading correct?

<comment><USER21> You are right. But it's not needed in Lobster, because threading model is different. It doesn't have concurrent access problems:

> Lobster built-in multi-threading functionality ... is different from multi- > threading in most other languages, in that it does not allow threads to > share memory or any other VM state.

[http://aardappel.github.io/lobster/language_reference.html#m...](http://aardappel.github.io/lobster/language_reference.html#multi- threading)

</comment></comment></comment><comment><USER23> In the event that it helps anyone, the following is how I think of Rust ownership stuff:

1\. Ownership-based memory management is statically elided reference counting.

2\. Borrowing (shared and mutable) is statically elided reader-writer locks.

<comment><USER7> > Ownership-based memory management is statically elided reference counting.

One difference I'd want to highlight here, which sometimes trips people up: Taking a reference to a Rust object has no effect on where that object's destructor runs. It can make the program fail to compile, if the reference lasts too long. But if the program keeps compiling, then the object's destructor is always running at the same place it was before.

</comment></comment><comment><USER24> Somewhat unrelated but does somebody have the 30 minutes guide to reading rust from 5 days back?

<comment><USER19> [https://fasterthanli.me/blog/2020/a-half-hour-to-learn- rust/](https://fasterthanli.me/blog/2020/a-half-hour-to-learn-rust/)

<comment><USER24> Thanks!

</comment></comment></comment><comment><USER25> They look pretty simple and intuitive.

From what I heard about rust's learning curve, I expected complex rules and corner cases.

</comment><comment><USER26> Some commenters mention Rust has compile-time data-race checking. Is this correct? From what I did understand it will only enforce a mutex to be locked before you can access specific data. However if there is no mutex, data-races won't be detected at compile time?

<comment><USER5> It is correct. Rust prevents all data races at compile time, _unless_ you write incorrect unsafe code. This is why people try to write as little unsafe as possible. This has nothing to do with Mutexes; mutexes are provided by the standard library and the language knows nothing specific about them.

<comment><USER26> I understand. It is actually kind of easy to comprehend by remembering the borrow checker will only allow one single mutable reference at a time.</comment></comment></comment>


IBM 704 Scientific Computer - <AUTHOR> http://www.zl2al.com/blog/category/ibm-704-computer/

<comment><USER2> I've always loved hearing about our heritage as an industry. This article reminded me of when I made a pilgrimage to the Computer History Museum in Mountain View and saw a replica (working!) Babbage Engine amongst a bunch of ancient and obsoleted hardware. It's fascinating to see the progress we've made in only a few decades!

<comment><USER3> Can that rate of progress be sustained or is this a 'path dependence' sort of thing where niches get filled early on? I have no idea but would appreciate views

<comment><USER4> I'd imagine it would be sustained. Every year more and more money is poured into technology R&D as it becomes increasingly important. This helps match the difficulty of further development. Far in the future this may be an issue, but I doubt it will be an issue within the next decade.

</comment></comment></comment><comment><USER5> PDF facsimiles of some original manuals are here: [http://bitsavers.trailing- edge.com/pdf/ibm/704/](http://bitsavers.trailing-edge.com/pdf/ibm/704/)

In addition to the manual for the computer itself, describing the assembly language and so forth, these include documentation for the earliest versions of Fortran.

Bitsavers has a lot of neat stuff on all sorts of old computers, including other old IBM systems, the B5500, (recently mentioned here) and a whole lot of old DEC equipment.</comment>


Looking for feedback on new Google-finance-style graph-based weather site - <AUTHOR>

We just opened the public beta for http://weatherspark.com, taking inspiration from the interactive graphs available on Google Finance. We'd love your feedback on it.
The site contains all of the worldwide weather station data available back to 1948 (down to the hour!), and makes it available in an interactive graphing interface. In addition to all the historical data, there are also integrated forecasts from several sources, and detailed records and averages (also down to the hour!) that are shown in the background in order to provide context.
The site is intended to serve your daily weather needs, to help inform long-range travel decisions, and to allow geeking out on the raw data.
A few cool random views:
An average day near the end of July in San Francisco (it is cloudy in the morning, clear in the afternoon, and almost never rains): http://weatherspark.com/#app;a=USA/CA/San_Francisco;t0=07/23;t1=07/28
The monsoon in Mumbai, India (the rain is so dominant that it cools down the air for three months, creating a neat multi-modal yearly temperature curve): http://weatherspark.com/#app;a=India/Mumbai;t0=01/01;t1=12/31
That cold snap in Dallas around the Super Bowl this year that was all over the news (turn on the wind speed and direction graphs and you'll see the wind change from southerly to northerly just as the cold snap starts): http://weatherspark.com#app;a=USA/TX/Dallas;t=360209;mspp=900000
Average late July in Houston (the thunderstorms roll in in the afternoon around 4pm typically): http://weatherspark.com/#app;a=USA/TX/Houston;t0=07/23;t1=07/28
The full year of 2010 in my home town (Madison, WI): http://weatherspark.com/#app;a=USA/WI/Madison;t0=2010/1/1;t1=2010/12/31
Please take a look and explore the data.  Don't forget to pan & zoom, and to turn on other graphs! :)
Cheers, James <comment><USER2> There's such a thing as too much data. I'm looking for information.

I want to be able to set my trip range and make a list of destinations. I want to be able to set options like "I prefer to travel to Hawaii when there is less rain". I want to travel to Paris when the weather is between 60 and 70 and never below 55 or above 85 regularly. I want to avoid clouds and rain at all cost.

The data will turn geeks on, it won't sell to non-geeks. Shoot for information.

<comment><AUTHOR> Great point. We are 100% on board with this (in fact, your Hawaii use case is one of the actual reasons why we started this project)! As a two-man shop we had to prioritize and decided to create the geek tool first and then start expanding the tabs to cover more focused use cases like yours.

<comment><USER2> Good luck with the project. Remember less is more; especially when handling copious amounts of data. There's nothing wrong with making a tool that has a touch span of 45 seconds, provided the user leaves with everything or more than expected.

<comment><USER2> I spent some more time with WeatherSpark this morning, wanted to offer some thoughts on how this would prove to be very useful for me and others like me.

I would like very much to have a trip or travel plotting function. Origin point, traffic, wind, weather and a summary for distinct points in the journey.

For example; departing by car from Richmond, CA at 10:30AM on Saturday and heading to Healdsburg, CA, remaining 5 hours and returning by the fastest route.

Departure time, travel time, weather summary along the way combined with traffic or potential traffic delays. The ability to set how long I will be at each point and a summary of weather impact at such a location. For me, less about the data and more about whether I need foul weather gear, extra water in the car due to delays, or snow chains.

Another example is planning a business trip, or any other kind of trip. Knowing what to expect within a set range of times is much more useful and practical than knowing when the best weather conditions MAY be to support pleasure or optional travel. I do 90% more business travel on demand than I do pleasure.

Example: departing Richmond, CA to San Francisco International Airport. Depart on UNITED 3474 to Cleveland, OH on a specific date and time. Travel by car from Cleveland airport to Wooster, OH, remain for 4 days, return by car to Cleveland Airport, return on UNITED 6761 flight and time from Cleveland, through Denver on UNITED 423 to San Francisco, then obviously, the drive home.

Being able to enter or, even better, upload or automatically link to an itinerary, and understand weather, wind/chill, rain/snow, delays, in a simple and predictive manner is really helpful. As long as it's fast and incorporates into the other tools I use for travel planning.

<comment><AUTHOR> Thank you for the suggestion (and for all your comments)! We really appreciate the feedback. Travel is a direction that we are very excited about. I've added your comment to our ticket tracker, so we'll revisit it when we get the travel features.

</comment></comment></comment></comment></comment><comment><USER3> Very nice interface! I just have to comment since I've been building for a fee weather applications in my spare time for a little while. I know what a mess it can become, especially since you rely on different sources.

I really like how you show the mean and distribution in the background.

I am surprised by the absence of precipitation accumulation, especially since that is often a valuable information for many people who look at long time weather.

Also I don't think the horizontal marker adds information since you show the value for each curve at the cursor, I feel it just clutters the interface.

The meaning of the icons is not always obvious, I am unsure how to interpret two snowflakes out of three or two raindrops out of four etc. It doesn't seem to be tied to the PoP. The intensity maybe?

<comment><USER4> Thanks!

We're working on precipitation accumulation - there are some data fidelity problems that we're trying to solve, then we'll get that in.

The horizontal marker is intended for comparing across the series - i.e. does this peak extend further up than this other peak over there. There's a lot of action going on around the mouse cursor, we'll see if we can pare that down without losing the key information.

Icons: 1 out of 2 snowflakes etc is the expected intensity of the precipitation (i.e. light snow, heavy snow, etc). The probability is reported just next to the intensity in the icon series if you're at a zoom level where the labels fit.

We don't have a legend for the icons yet, need to add that.

<comment><USER3> What do you mean by data fidelity, you mean about how to represent the data so that it is comparable? I can imagine it is a problem especially since your scale can change. I know I am not showing accumulations graphically for a number of reasons myself. For a while I was showing snow accumulation on a graph where it would literally accumulate.

Or something about your data sources? I work with data from Environment Canada and the only annoying thing with the data was making meaningful unit conversions when the nature of the accumulation is snow.

<comment><AUTHOR> Hi, by "data fidelity" we mean that there are a lot of errors and irregularities in the liquid-equivalent precipitation measurements reported by the stations. Some stations don't report it at all, or not reliably, and some report it but with internal inconsistencies. For example, stations may report in 1-hour, 6-hour, or 12-hour intervals, but they frequently report 1-hour measurements that don't even come close to adding up to the 6-hour measurements. We just want to make sure we take some time to understand these issues with the data feeds before we start publishing them.

The snow depth feed is also a really cool graph. We have it more or less ready, but it is perhaps the least reliable measurement.

For example, during that recent snow storm in Chicago it reported some pretty crazy big snow depth numbers for a couple reports and then without correcting the old reports just dropped the snow depth by more than a meter in the next report. This is fine if you have a human reading the report, but it makes the graph look really weird.

</comment></comment></comment></comment><comment><USER5> I absolutely love it, but I'm a total data geek. Just as one anecdotal thing that I got out of the app: 2 weekends ago was ridiculously nice in San Francisco. If you live in SF it was a weird 2 days of perfect weather in the midst of an otherwise fairly cold winter. If you look on the charts there it pops out immediately. There's a huge spike for Feb 5 and 6. Suddenly it jumped from low 60s/high 50s to a nice 72 degrees and then immediately right back down again after the weekend. It was really cool to see my personal experience of the weather quantified like that.

One quick suggestion: show the day of week in the tooltip where you show the date (when zoomed into showing single days at a time obviously). That would make it easier for me to relate the data to my memory of the weather.

<comment><USER4> Thanks - that's exactly the type of observations we're hoping to enable!

Tooltip: Added & deployed, hit reload to get the new app.

</comment></comment><comment><USER6> Very nice. Climate is what you expect, weather is what you get.

The interface is daunting, though. I'm not quite sure what it's trying to tell me.

[http://weatherspark.com/#app;a=USA/CA/San_Francisco;t0=02/16...](http://weatherspark.com/#app;a=USA/CA/San_Francisco;t0=02/16;t1=02/17)

It says 2012 on the bottom bar. I'm uncertain whether this is a bug, a forecast for 365 days from now, or an average since 1948 or... what, exactly.

I also don't get a feel for the accuracy of the predictions, especially at what time range. Sure, I can see that in SF winters are wet and summers are dry, but I knew that already. Can it tell me something interesting about a shorter period, like late April?

<comment><USER4> The far future is the averages (light blue background) - the forecast is only in the "Forecast"-zone (light purple), but perhaps that can be made more clear (e.g. changing 2012 to "Averages" in the x-axis or something similar).

Accuracy of predictions: the forecasts are as accurate as forecasts are, and we don't influence that.

The averages (mean, 10th percentile, 90th percentile, etc) aren't accurate in any predictive sense - they're just the stats for the recorded history for the station. They tell you what you can reasonably expect, but YMMV.

For SF in late April you can see that the average temperature is steadily rising and the chance of precipitation steadily declining: 62F high on average in early April, 65F towards the end. 8% precipitation vs 5% means almost half as much rain towards the end - I'd hold off until the last week of April if it's an option ;)

</comment></comment><comment><USER7> Totally geeking out on this at the moment. This is absolutely awesome!! The only thing I would say is that you might consider adding an additional simple interface (like a mobile interface) for the less savy viewer. I think the ability to visualize the forecast is really powerful, I'm just picturing my mom looking at this and seeing too many options.

Options are great for us data geeks, but a very simple city forecast page that harnessed your forecast visualization technique could be great for a much wider audience as well.

<comment><AUTHOR> Great suggestion! Yes, we are excited to start playing around with ways to make it more accessible to a wider audience. But we thought it would be fun to start with the geek tool :).

</comment></comment><comment><USER8> Overall I really like it, I don't know whether it's intentional but for today in Oakland CA the area to the left of the yellow "now" bar in cloud and precipitation is blocky columns that don't really tell much. To the right is the great graph of prediction vs history and I'd expect this to look similar to the left but reflect actual data instead of prediction.

<comment><USER4> For precipitation the prediction & averages are in percent, but the past is in actual hours of precipitation - hence the blockiness for the past (the vertical axis is from 0-1 hours when zoomed in).

For clouds it's percent cloud cover, so a full block means fully overcast.

</comment></comment><comment><USER9> Wow -- this is great. Canadians love to talk about the weather and this provides endless conversation topics!

Looking at the recent data for Ottawa, ON there appears to be a glitch on Jan 17, 2011. When zooming in and out the high line jumps up to 19C at some scales and falls back to normal at others. It wasn't that hot :(

<comment><AUTHOR> Yes, the raw data feeds have occasional blips like that (more so in some stations than in others).

It is a top priority to write some good automatic quality control code, but we didn't want to do a bad job and end up accidentally filtering out real data (we've discovered, for example, that some of NOAA's quality control filters have very high rates of incorrectly deleting measurements that are actually extremely plausible).

We want to take a proper statistical approach, which requires labeling a lot of examples of these kinds of blips, and we just haven't had time to do that yet.

<comment><USER9> I'm not sure this is a raw data blip, since it seems to change based on the zoom level.

19C appears to be the historical high for that day, but is sometimes included in the band indicating the actual range.

<comment><AUTHOR> It is definitely a blip. The reason it doesn't appear in all the zoom levels is that the four-hourly zoom level takes the average temperature of the hourly data over the four-hour period. Once you go up to the daily zoom level we switch to showing the high and the low, and you can see the blip again. That historical high is due to that point.

Actually, I'm just sitting down today to start the process of writing quality control filters to get rid of this sort of blip. So hopefully it will be gone soon! :)</comment></comment></comment></comment>


A free app makes a TI graphing calculator make music - <AUTHOR> http://irrlichtproject.de/houston/ <comment><USER2> Aw, no 89Ti version :/ How hard would it be to port it?</comment>


Project Fi Sucks, they changed my number by mistake - <AUTHOR> https://www.reddit.com/r/ProjectFi/comments/7p3pxc/project_fi_is_terrible_they_changed_my_number_by/ <comment><AUTHOR> It's a nightmare! I'd appreciate any advice or if someone had a similar experience?

<comment><USER2> I experienced a different issue.

I kept receiving different phone calls from 650 2345 xxxx numbers. (650 2345 are made up)

the first 7 digits are the same as that of my number. only the last 4 digits are different.

normally I won't pick up. But some number kept calling and I received this kinda of phone call quite often.

So, one day I picked up, on the other side, it was an angry lady asking who I am, and why I kept calling her. I said I didn't, I was just picking up her call.

She said "stop calling me again!" then hang up ....

Then I emailed google about the issue. they seemed to fix for a short period of time and then it happened again. I switched to t-mobile then.</comment></comment>


Ask HN: Please suggest topic for blogging - <AUTHOR> <comment><USER2> I hate to be that guy but if you can't come up with a topic of your own, or write about what interests you, you probably shouldn't blog.

<comment><USER3> Well yeah, I was gonna say that too.

 _Coding Horror_ blog has quite a few great articles on the subject of blogging - why, what, how, when to write, for whom etc.

</comment></comment><comment><USER4> Career choices for younger merchant sons in Venice in the Quattrocento.

</comment><comment><USER5> Your bio says "Lives in Kolkata, India."

Anything about life in India as a developer, how the culture is different to western etc. Would be interesting.

Blog about stuff you know well and can share deeper insights into.

<comment><AUTHOR> Thank you for this one!

</comment></comment><comment><USER6> Lisp macros, focusing not just on the resultant code but also the moment of realizing a macro'd be useful.

</comment><comment><USER3> Things easier to do in a Perl one-liner than in an AWK one, and vice versa. (and maybe other languages)</comment>


FCC: We aren't banning DD-WRT on Wi-Fi routers - <AUTHOR> http://arstechnica.com/information-technology/2015/11/fcc-we-arent-banning-dd-wrt-on-wi-fi-routers/ <comment><USER2> It's interesting (depressing) to me, that the FCC thinks that hardware vendors should be responsible for what their hardware does once it leaves their hands. If we applied the same logic to other industries, there wouldn't be a firearm manufacturer left in the USA.

Is this an actual problem? Are there people running DD-WRT in a way that is wreaking havoc on other communications? I can count on one hand the number of people I know who have played with DD-WRT, and I've worked with hundreds of geeks in my career. It feels like the FCC is trying to regulate a problem that doesn't exist yet, and it makes me wonder what the motivation behind it is.

<comment><USER3> Actually it seems very similar to the example you provided.

A similar scenario would be if a firearms manufacturer designed a semi- automatic rifle (one trigger pull = 1 shot fired) that easily could be modified to be an automatic rifle (one trigger pull = multiple shots fired). Former is legal, the latter is not. If such a firearm starting becoming a favorite of criminals because of this feature, a vast majority of gun enthusiasts would have no problem with BATF requiring the manufacturer to put safeguards in place (there are perhaps a small sliver of extremists that might object, but nowhere near the degree to which an equal-but-oppositely extreme sliver of gun control advocates would have you believe).

The FCC is really just saying that if you make a device that you want to get certified, and it is physically capable of transmitting outside of the parameters for which it is being certified, it wants to know what steps you are putting in place to ensure that the it can't easily be modified to do that.

And to answer your question - yes, people are already modifying consumer routers to use outside of Part 15... for example [http://www.broadband- hamnet.org/](http://www.broadband-hamnet.org/) ... those are licensed operators of course but anyone could do this, licensed or not.

<comment><USER4> Honestly, as someone who associates with a lot of gun enthusiasts, I think that the AR platform is quite easily modified into fully automatic -- just replace the sear from a semi-automatic sear to a full auto sear.

You have to have a BATFE approval and pay a tax stamp to possess a full auto sear, but the work in switching from semi to full auto is pretty minimal.

A more apt scenario that people would clamor behind is a semi-automatic firearm that had a fully automatic failure state. That would be terribly unsafe, and everyone on both sides of the gun debate would be demanding it got fixed, just as they would if a firearm were on the market that could accidentally fire when dropped.

Both of those used to be fairly common scenarios, but are now both exceedingly rare thanks to advancements in gun safety.

<comment><USER5> I'm not familiar with guns - what's a sear?

Without knowing that, I'm gonna go ahead and make a comment that may not make sense: I think the idea is that it shouldn't be _trivially_ simple to convert a semi-automatic rifle into an automatic rifle. E.g., it can't be done by putting a paperclip into some part of the mechanism, or slightly filing down a metal part.

If getting a full auto sear is a non-trivial process (which it seems to be) and making one from scratch isn't trivial either, then gun manufacturers seem to have gone to reasonable lengths to prevent their guns from being converted to full auto.

<comment><USER4> A sear is, basically, a piece of metal. It's part of the trigger assembly. Speaking simplistically, it is the thing that gives the trigger pressure -- it holds back the striking mechanism until your trigger pull releases it.

[https://en.wikipedia.org/wiki/Sear_(firearm)](https://en.wikipedia.org/wiki/Sear_\(firearm\))

This is an animation of a semi-automatic sear (in which the sear is the green part): [http://mcb-homis.com/blog/trigger-animation.gif](http://mcb- homis.com/blog/trigger-animation.gif)

This is an animation of a fully automatic sear (in which the sear is blue): [http://mcb-homis.com/blog/m16animation1ww1.gif](http://mcb- homis.com/blog/m16animation1ww1.gif)

Taking out a semi-automatic sear and replacing it with a fully automatic sear is trivial. Converting a semi-automatic sear is slightly more difficult, as it requires precision, and a supplementary catch (to keep the firearm from always firing always).

If people aren't committing crimes with fully automatic firearms, it isn't because the process of obtaining fully automatic firearms is difficult, because it isn't. You can get butt stocks that replicate fully automatic fire for less than $50. Fully automatic fire is just silly to use. If you miss with the first shot, you're almost certainly going to miss with subsequent shots, so for anything requiring accuracy (which is almost everything you would do with a firearm short of perhaps intimidation), converting to full auto makes it less effective.

</comment></comment></comment></comment></comment><comment><USER6> TL;DR:

 _Describe, if the device permits third-party software or firmware installation, what mechanisms are provided by the manufacturer to permit integration of such functions while ensuring that the RF parameters of the device cannot be operated outside its authorization for operation in the US. In the description include what controls and /or agreements are in place with providers of third-party functionality to ensure the devices' underlying RF parameters are unchanged and how the manufacturer verifies the functionality._

This sounds like it permits open source drivers and OSs, as long as the hardware enforces FCC compliance.

However, I see a problem with the "FCC" in "FCC compliance". This rule doesn't sound good for world-roaming WiFi adapters, i.e. ones which are validated to physically work in multiple regulatory regimens and try to comply with current local regulations simply by not transmitting on frequencies not allowed everywhere in the world until they connect to some AP working on this frequency. Obviously, the assumption is that APs are compliant.

AFAIK at least Atheros makes such adapters (for laptops, phones, etc) and the channel limiting logic is implemented in drivers, which are open source for some platforms. I wonder how are they going to deal with such regulations.

Not that this would be the first time radio regulations screw mobile users, btw. You may think that even if your laptop's WiFi card is locked to channels allowed in one country, you can get a USB dongle from another country and use it there. Not that easily. Some cards made by Atheros (dunno about other vendors) are validated only for operation in certain regulatory domains and this information is stored in EEPROM on the card. Their Linux driver reads the country code from the card and passes it to the wireless stack, which in turn immediately locks out all frequencies and power levels disallowed in this country.

When I asked about this behavior, the WiFi stack maintainer's response was that they treat each region-locked card in the system as a "hint" that the system may be operating in this region and try to comply with this region's regulations just to be safe. Madness and paranoia. This maintainer was an employee of one WiFi hardware vendor.

I ended up replacing my laptop's WiFi card with one whose drivers are based on independent reverse-engineering effort, simply because they didn't bother passing regulatory codes to the WiFi stack and messing up USB dongles.

<comment><USER7> You can quite easily change your regulatory domain on Linux, as well as change stored settings (through wireless-regdb) in it. CRDA is run in user-space.

For example, `iw reg set` to BO ro JP will remove many power and channel limitations.

Yes, it's possible to have these settings stored in a tertiary firmware, but it's not common anymore. The hardware is the same, the driver and stack simply limit it based on what the OS requests.

<comment><USER6> 1\. `iw reg set JP` is exactly what this regulation seeks to prohibit, i.e. if you are selling WiFi hardware in the US, you have to be damn sure that no one will be able to switch it to channel 14.

2\. Even with `iw reg set JP` you won't be able to go above channel 11 if your system contains an Atheros adapter certified for US market only. Even using other hardware, suitable for the job and certified by whatever agency Japan has.

The only solution is `rmmod ath` or patching the mac80211 stack. Or avoiding Atheros hardware, as I do. Not that I have anything against Atheros, I'm sure they wouldn't bother implementing this bullshit logic if they didn't have to, but their hardware is simply a PITA to use because of this.

</comment></comment></comment><comment><USER8> No mention of Dave Taht and Vint Cerf's open letter to the FCC then? Sad.

[http://fqcodel.bufferbloat.net/~d/fcc_saner_software_practic...](http://fqcodel.bufferbloat.net/~d/fcc_saner_software_practices.pdf)

<comment><USER6> This letter calls for quite radical and, dare I say, controversial changes. Did you really expect to see this changes adopted overnight?

Or are you complaining that Arstechnica didn't mention it?

<comment><USER9> How are those changes radical or controversial?

<comment><USER6> Giving users full control over the hardware and expecting that they will follow regulations is exactly the opposite of what RF regulatory looked like throughout the last century.

And if you want to understand the "controversial" part, just go to any company and ask what they think about being required to open source their precious firmwares and fix bugs in timely manner under the threat of getting banned from the market.

</comment></comment></comment></comment><comment><USER10> It's a step in the right direction. The concern I have is that "disabling" the ability to use 3rd party firmware is still the primary means of compliance which is prima facie accepted, whereas if you don't disable, then you have to make the case for why you comply, including coordinating with random 3rd parties and FCC may decide you haven't done enough. Are manufacturers going to take this risk?

Ideally for a manufacturer to take the stance that they comply through disabling 3rd party firmware updates (versus the preferred method of... what exactly?) they should have to work harder than the alternative, but at least it should be an equally "certain" process and outcome. That shifts the calculus of a risk adverse company deciding how to comply.

</comment><comment><USER11> So they changed the language, and the new language is

> Describe, if the device permits third-party software or firmware > installation, what mechanisms are provided by the manufacturer to permit > integration of such functions while ensuring that the RF parameters of the > device cannot be operated outside its authorization for operation in the US. > In the description include what controls and/or agreements are in place with > providers of third-party functionality to ensure the devices' underlying RF > parameters are unchanged and how the manufacturer verifies the > functionality.

Hardware locking to correct frequencies would satisfy this requirement. But it also sounds like getting in touch with the authors of common third-party firmwares, and getting them to agree to stay within FCC might suffice? That isn't totally clear, but it seems like that would be the ideal: hardware manufacturers some risk of power users reprogramming their radios incorrectly, but keep an eye on things so no one publishes software that leads people into doing it by accident or makes it too easy.

</comment><comment><USER12> It seems to me that transmitter chipsets should work with an optional resister/register that is hard-wired to the market.. in this way the device firmware won't be able to utilize the antenna out of band, or at least the drivers should/could use this as a guide, and with most device drivers of this type being included as closed/source blobs, it would be less of an issue while allowing for userspace mods like dd-wrt, open-wrt and tomato to continue working.

edit: Maybe having a dip switch panel under the cover, so it _could_ be user modifyable, but not the "default" for a region.

</comment><comment><USER13> While they aren't banning DD-WRT, they are creating restrictions for manufacturers. The easiest way for a manufacturer to meet the new rules is simply to not allow flashing third-party software.

Even if they don't intend to ban DD-WRT, their rules may indirectly eliminate consumer ability to use it.</comment>


'Hey Siri, I'm getting pulled over': Records police interaction, sends location - <AUTHOR> https://www.fox29.com/news/hey-siri-im-getting-pulled-over-iphone-feature-will-record-police-interaction-send-location <comment><USER2> This title makes it feel like it's an Apple feature, but really it's just a Shortcut someone put together.

It basically just turns down the volume, texts your location to an emergency contact, and opens your camera. It doesn't upload the footage in realtime to a central server as other apps do.

<comment><USER3> It does push it to iCloud or Dropbox though.

<comment><USER4> Can you clarify this, does iCloud or Dropbox actually receive video in real time as it's being recorded, or does it only start uploading after the recording is done? Because in the latter case, I doubt it will do much good -- unless perhaps sleeping an iPhone during a recording saves what has been recorded so far and uploads it in the background, which I'm also not sure of.

</comment></comment></comment><comment><USER5> This is cool - I think smartphones are are best defence against violent police oversteps. Now everyone has a camera with them and we are seeing the results. Democratisation of surveillance.

<comment><USER6> > This is cool

Indeed it is. Why install CCTV cameras when everyone is their own camera- person. Solves the low quality camera problem and multi-angle footage. However...

> Democratisation of surveillance.

Mixed with social media, it's now more like self-surveillance. This is just the start and Nextdoor neighbourhoods take this to dystopian levels. But one clever man once compared this to 'Stalin's Dream'. If that's his dream, then it will soon be everyone's nightmare.

<comment><USER7> [https://news.ycombinator.com/item?id=19529921](https://news.ycombinator.com/item?id=19529921)

</comment></comment></comment><comment><USER8> I am black. If I was in the United States I'd have a dashcam and would wear a bodycam if possible.

<comment><USER9> The data doesn't seem to back up your claim. [https://en.wikipedia.org/wiki/Police_use_of_deadly_force_in_...](https://en.wikipedia.org/wiki/Police_use_of_deadly_force_in_the_United_States)

<comment><USER10> Deadly force isn't the only way police commit violence against impoverished Americans, or against Americans who aren't white (regardless of economic class). You don't have to be murdered by the police for your life to be effectively ended when they make up BS about assaulting an officer, resisting arrest, etc.

<comment><USER9> Completely agree. Although the data doesn't show african american's are killed at a higher rate(in fact it shows the opposite) it does show that they are discriminated against at a higher rate. Pulled over more, etc.

<comment><USER11> > Although the data doesn't show african american's are killed at a higher > rate

Wait, what? Take a second look at the first 3 paragraphs, and then the "Racial Patterns" section of that Wikipedia article you linked.

When people say that police killings aren't racially motivated, they are disputing the _causes_ of the disparity in race-based deaths, not the disparity itself.

I mean, you can just do the math from recorded police shootings yourself, and you pretty consistently across multiple years get death-per-million numbers for black communities that are around 1.5-2.5x as large as for white communities. Black men are pretty objectively killed at higher rates than white men, the studies you're talking about are questioning _why_ that is and whether officer bias and/or systemic racism plays a role in those numbers.

<comment><USER9> Did you read the `Racial patterns` section and look at the data from the FBI?

<comment><USER11> Yes. You're going to have to direct me to a quote, I don't know what you're referring to. What I see is:

2015:

> A 2015 study found that unarmed blacks were 3.49 times more likely to be > shot by police than were unarmed whites. [...] Another 2015 study concluded > that black people were 2.8 times more likely to be killed by police than > whites.

2016:

> According to The Guardian's database, in 2016 the rate of fatal police > shootings per million was 10.13 for Native Americans, 6.6 for black people, > 3.23 for Hispanics; 2.9 for white people and 1.17 for Asians. [...] Another > study published in 2016 concluded that the mortality rate of legal > interventions among black and Hispanic people was 2.8 and 1.7 times higher > than that among white people.

2018:

> A 2018 study found that minorities are disproportionately killed by police > but that white officers are not more likely to use lethal force on blacks > than minority officers.

2019:

> A 2019 study in the Journal of Politics found that police officers were more > likely to use lethal force on blacks, but that this was "most likely driven > by higher rates of police contact among African Americans rather than racial > differences in the circumstances of the interaction and officer bias in the > application of lethal force." A 2019 study in the journal Proceedings of the > National Academy of Sciences (PNAS) found that blacks and American > Indian/Alaska Natives are more likely to be killed by police than whites and > that Latino men are more likely to be killed than white men.

\----

I see exactly one study in this section that disputes the disparity itself, and that study was widely criticized and ended up issuing a correction:

> A 2019 study in PNAS concluded from a dataset of fatal shootings that white > officers were not more likely to shoot minority civilians than non-white > officers [...] The study was widely criticized by other academics, who > stated that the study's conclusion could not be supported by the data. [...] > PNAS issued a correction to the original article.

I don't see data from the FBI mentioned in the racial disparity section. Maybe I'm missing what you're referring to.

Again though, you don't need to do a complicated study to find the disparity itself. You can literally just add up the number of deaths for each race and then divide by population numbers in the US for black/white communities. You'll get higher per-million numbers for black communities than for white ones. I'm not sure how someone could dispute that, unless you're arguing that the Guardian is under-reporting white deaths or something[0]. If you want to debate the causes behind that disparity, then that's a separate conversation.

[0]: [https://www.theguardian.com/us-news/ng- interactive/2015/jun/...](https://www.theguardian.com/us-news/ng- interactive/2015/jun/01/the-counted-police-killings-us-database)

<comment><USER9> You can't look at percentage of population but percentage of who commit crimes.

[https://www.bjs.gov/content/pub/pdf/htus8008.pdf](https://www.bjs.gov/content/pub/pdf/htus8008.pdf)

> Blacks were disproportionately represented as both homicide victims and off > enders. Th e victimization rate for blacks (27.8 per 100,000) was 6 times > higher than the rate for whites (4.5 per 100,000). Th e off ending rate for > blacks (34.4 per 100,000) was almost 8 times higher than the rate for whites > (4.5 per 100,000) (table 1)

From the article

> A 2015 study by Harvard professor Roland G. Fryer, Jr. found that there was > no racial bias in the use of lethal police force between black and white > suspects in similar situations. The study did, however, find that blacks and > Hispanics are significantly more likely to experience non-lethal use of > force.

> A 2016 study published in the journal Injury Prevention concluded that > African Americans, Native Americans and Latinos were more likely to be > stopped by police compared to Asians and whites, but found that there was no > racial bias in the likelihood of being killed or injured after being stopped

<comment><USER11> See my other comment[0], you're making two separate claims here. _Why_ blacks are disproportionately killed by police is a conversation that might be worth having, but it doesn't change the fact that they are disproportionately killed.

As an analogy, a truck driver might be less likely to crash or be killed on any specific drive than I am. However, a truck driver also drives a _lot more_ than I do, so a truck driver is still more likely overall to die in a vehicle crash than I am.

In the same way, even if we lived in a world where blacks were less likely to be killed in an individual police interaction, that doesn't change the fact that a black person is still more likely overall to be killed by a police officer than I am.

[0]: [https://news.ycombinator.com/item?id=23547106](https://news.ycombinator.com/item?id=23547106)

<comment><USER12> Then the problem is the truck driver is driving too much. He should drive less.

<comment><USER11> Which is why we're seeing calls by protestors to reduce overall police presence in cities and to instead migrate various police responsibilities onto social workers with more directly applicable training.

Naming issues aside, reducing the amount of time the 'truck driver' spends on the road is one of the biggest goals of the "defund the police" movement. But again, that's a separate discussion.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> It records it if you have the Siri Shortcuts app installed and download that user script.

The article points out the Siri command is only for iPhones, but it could also be a Google Routine or an Alexa skill, or there are standalone apps for all three platforms that do the same thing.

</comment><comment><USER14> @mods can we get this headline changed? as other comments have pointed out, it's pretty misleading.

</comment><comment><USER15> It is a very strange world where we need technology to protect us from those who protect us.

</comment><comment><USER16> I think this is an outstanding idea. But if it's to be credible, the recordings need to be unmodifiable/undeleteable by the user, and immediately available to law enforcement.

Heads I win, tails you lose is not credible. It's just riot bait.

<comment><USER17> >the recordings need to be unmodifiable/undeleteable by the user and immediately available to law enforcement.

That would be a 5th Amendment violation, and possibly a privacy matter.

<comment><USER16> That's probably true, from a legal perspective.

As a practical matter, though, being able to pick and choose only the most inflammatory and out-of-context audio/video pretty much ruins this as a real source of truth.</comment></comment></comment>


Web users are getting more ruthless and selfish when they go online - <AUTHOR> http://news.bbc.co.uk/2/hi/technology/7417496.stm <comment><USER2> Not reading advertising copy is called being "selfish" now?

<comment><USER3> The article didn't say anything about advertising copy, it mentioned that web users typically ignored highlighted promotions and editorial gimmicks.

</comment></comment><comment><USER4> anyone else think this study is just intuitive analysis and completely specualtive. i wonder exactly which means were used to deduce the report.

its like saying people who go to restaurants are becoming more choosy as to which restaurants they go to and what food they eat, having become accustomed to the whole eating-out dealio.

i hope no-one got paid for the findings and if they did, i want that job.

Nielsen: "Search engines rule the web"...they do huh? gosh he has a point there.

me: web users are increasing their activity and are becoming more and more accustomed to manage their affairs online with very user-friendly apps...keep building.</comment>


How To Build a Viral Microsite - <AUTHOR> http://www.jasonshen.com/2012/how-to-build-a-viral-microsite/

<comment><USER2> Great idea to write about/give a strategy for this, I've never seen this addressed before. What's unique about these sites is how rarely they actually do anything - they tend to be viral jokes, but they don't function towards any sort of business goal besides a nice add to the design portfolio. Part of that is cause that's simply required to get these to go viral - any sort of business mention causes it to crash and burn. But minimalism and a rough themeatic connection can serve to help, but we really haven't seen it _consistently_ done other than for the purposes of a very cool thing to add to the resume, which can indirectly make a few people some coin.

<comment><AUTHOR> Yeah, I was going to write about how the best ones tend to lack advertising or a blatant commercial purpose, and that's what makes them so sharable. People don't feel like they're just promoting some business's marketing campaign or helping some random guy make money off PPC ads.

</comment></comment><comment><USER3> Good writeup Jason. I also clicked on the rejection therapy post by accident... ha, that was hilarious.

<comment><AUTHOR> Thanks! Let me know if there is anything you think I missed or got wrong!</comment></comment>


Startup Building Data Centers on Ships - <AUTHOR> http://www.datacenterknowledge.com/archives/2010/08/09/ids-readies-data-centers-on-ships/

<comment><USER2> The cooling makes a reasonable amount of sense but...

Ships need maintaining - it presumably has to be dry docked every decade or so. What happens to your server then?

And what companies are out there that could/would take 3,000 machines if this is successful?</comment>


Stormpulse Raises $1.3m Series Seed - <AUTHOR> https://twitter.com/angellist/status/350659860653801472 <comment><USER2> 1387 days ago Matt Asked HN for help on his elevator pitch.

[https://news.ycombinator.com/item?id=814685](https://news.ycombinator.com/item?id=814685)

Since then, they got told "No" by several hundred people, switched business models, landed President Freaking Obama as an anchor client, and have created more actual value than a thousand mobifotosocialgames without ever once being in TechCrunch. And things are starting to work for them, in a serious way.

Drinks are on me when they IPO. (Which, disclosure, if they IPO I will probably be able to afford, since I invested in an earlier round.)

<comment><AUTHOR> Another fun thing about that thread is that Dave McClure commented on your edit of my pitch, and then 1387 days ago made 500 Startups second investment in Stormpulse in 6 months. :)

<comment><AUTHOR> Oops, I meant to say "1387 days LATER".

</comment></comment></comment><comment><AUTHOR> Had the idea in October 2004, did a breadth-first search for a business model for almost 9 years, and now finally ... convergence.

Just thought the HN community would like to know.</comment>


Google Developing Touchscreen Devices Using Chrome Operating System - <AUTHOR> http://online.wsj.com/article_email/SB10001424127887323549204578316900564812118-lMyQjAxMTAzMDIwMDEyNDAyWj.html <comment><USER2> <http://news.ycombinator.com/item?id=5254933></comment>


Why are some programmers paid more than others? - <AUTHOR> http://marginalrevolution.com/marginalrevolution/2012/01/why-are-some-programmers-paid-more-than-others.html

<comment><USER2> Probably no HNer's are surprised at the variance in programmer prices. What's interesting about this article is that for people outside the Hacker culture, this is a genuine, puzzling question. It goes to show that we've got quite a way to go before programming is well-understood among the general populace.

</comment><comment><USER3> Local cost of living, Current saturation of the market, Negotiating prowess during salary talks</comment>


Ask HN: Good place to publish a security model - <AUTHOR>

Dear Aunt Irma,
We've been working for a few years now on a very nice web development platform with a considerable array of security defenses. It's now high time to document & publish the security model. Any thoughts on where to do this? Project Blog? Academic Journal? OWASP Project Page? etc.
With coding love,
Yoric <comment><USER2> How are your security defenses different from those in OWASP's ESAPI project, or (even simpler) in Rails?

Where you should publish depends on how interesting your contribution is.

Your contribution would need to be very interesting indeed to make it through peer review. Given the odds, I probably wouldn't spend the time writing a formal paper.

<comment><AUTHOR> Parts of the defenses implement the ESAPI project. But some address very different attacks and/or application scenarios.

<comment><USER2> OK... keep going...?

</comment></comment></comment><comment><USER3> I've been wondering the same thing. Journals are mostly out of the question unless you've got time to spare. Conferences might be better if you've got something novel that can get through peer review, _and_ have a few months to spare.

Perhaps consider writing it up from a generic point of view, adding references where necessary, and post a link on HN and security mailing lists? Or submit a paper to arXiv?

<comment><AUTHOR> In this case, I believe that there's enough novel stuff to make it a conference paper, but not the time to make it through peer review.

> Perhaps consider writing it up from a generic point of view, adding > references where necessary, and post a link on HN and security mailing > lists? Or submit a paper to arXiv?

I'll think about it, thanks.

<comment><USER4> My experience with conference papers (albeit limited) is that it doesn't actually take that much effort to make it through the peer review process, so long as you've got something novel and interesting, and you've taken the time to find the correct context for it (correct conference, correct related work, etc).</comment></comment></comment>


Future of Software dev will become process of having long conversations with AI - <AUTHOR> http://www.quantumrun.com/prediction/future-software-development-future-computers <comment><USER2> The site seems down for me.

There is a lot of potential in the intersection of NLP, speech recognition and restricted languages for requirements engineering; something that I would dearly like to explore.

NASA did some really interesting work here a while ago ... it is a pity that this work was not released into the public domain.

</comment><comment> java-man ... using javascipt</comment>


West Oakland Is For Startups - <AUTHOR> https://medium.com/i-love-you-san-francisco/5142e32747e8

<comment><USER2> I used to bike from SF to Berkeley when our office was there and I would always start my East Bay leg of the trip from the West Oakland Bart station. It really is a huge shame that that area is such a dump. It's so incredibly conveniently located and there is plenty of land and I expect rent to be very cheap relatively speaking. I imagine that it would be a great place to do hardware startups, especially around American Steel, where a lot of people into art welding work out of.

</comment><comment><USER3> Having just placed a startup in SoMa, I'll say that the inconvenient CalTrain <-> BART transition is an issue. If you are looking to draw employees, mentors or investors from the peninsula, that one BART station makes a big difference. I expect this will change significantly once the new SoMa transportation hub opens and you have CalTrain lines that dead-end at a BART station.

<comment><AUTHOR> Yeah, the W. Oakland to South Bay connection is hard, both via SF and 880.

However, it's about as hard as it is for the SF Downtown <-> South Bay connection, since to get to Downtown from CalTrain, you have to pass by a BART station :-)

</comment></comment><comment><USER4> Not from SF here, but I study maps of it frequently for analysis work. Is there really not a single startup there??? I find this a bit hard to believe considering its proximity to downtown.

<comment><AUTHOR> I don't know of a single one.

There's lots of art stuff happening, but no tech/internet (which isn't that surprising).

<comment><USER2> AFAIK the American Steel warehouse there is the center of a lot of the big metal art stuff in the Bay Area.</comment></comment></comment>


Stephen Hawking's last Reddit comments - <AUTHOR> https://www.reddit.com/r/science/comments/3nyn5i/science_ama_series_stephen_hawking_ama_answers/ <comment><AUTHOR> "If machines produce everything we need, the outcome will depend on how things are distributed. Everyone can enjoy a life of luxurious leisure if the machine-produced wealth is shared, or most people can end up miserably poor if the machine-owners successfully lobby against wealth redistribution. So far, the trend seems to be toward the second option, with technology driving ever- increasing inequality."</comment>