Judge: It's OK If Best Buy's Geek Squad Nerds Search Your PC for Illegal Content - <AUTHOR> https://www.bleepingcomputer.com/news/legal/judge-its-ok-if-best-buys-geek-squad-nerds-search-your-pc-for-illegal-content/ <comment><USER2> Yea, the case is going the defendants way. I understand the idea that if a tech is going through your computer and stumbles upon evidence of a crime that they should be required to report it.

But I don't understand finding evidence in hidden sectors of the hard drive (that's far from stumbling across it). And when the FBI pays for evidence, it should have been thrown out right there.

<comment><USER3> I mean, in this case the hard drive was bad, and they were purposefully scanning the entire drive in hopes of recovering his data. I'd say it's only natural for somebody to come across hidden data when the entire service is to recover said data.

</comment></comment><comment><USER4> There's a lot more to the story than the headline. The judge has made a number of rulings, most of which are in favor of the defense.

People should read the article rather than reacting to just the headline.

</comment><comment><USER5> The only image "found" was a thumbnail from a known anti child abuse video (and not pornographic in nature).</comment>


Probiotics Found to Be Ineffective for Easing Symptoms of Kids' Stomach Bugs - <AUTHOR> https://www.npr.org/sections/health-shots/2018/11/21/669373363/probiotics-found-to-be-ineffective-for-easing-symptoms-of-kids-stomach-bugs <comment><USER2> Based on my own anecdotal evidence, I would agree with this.

A while back I damaged my gut. I experimented with many methods found on thousands of websites that talk about probiotics, fish oil, manuka honey, etc... All of those things just irritated my gut more and prevented healing. The fish oil did the most damage. It is a blood thinner and anti-coagulant. The manuka honey also did a bit of damage when it reacted and pushed many small bubbles into the blood stream in the leaky gut/brain barrier.

In the end, culling some of the bacteria with mastic gum and keeping it off the gut lining with diet cranberry juice was all that really worked. I also took K2-MK4 and K2-MK7 to keep the calcium in my blood from binding to the oxalate in the cranberry juice which can lead to kidney stones. Diet cranberry juice is my new best friend. Ginger root and aged garlic extract helped with the candida.</comment>


Ask HN: Can anyone review my resume and provide feedback? - <AUTHOR> I am trying for new job at top notch companies such as Goog/FB/NetFlix/Amazon/LinkedIn.
In the past I have received no reply at all.
Can anyone senior enough or working as lead / manager at these companies review my resume ?
A bit about me - I am not software engineer anymore. I do code on daily basis but it's more data /ETL vs writing core engineering applications. I have about 9 years of experience by now in data/analytics field. I work for a well known company but there are quite a bit of hurdles at my current job.
I really appreciate if anyone is willing to do so. Also, I request you to maintain confidentiality if you are going to review my resume. <comment><USER2> You're probably better off just removing identifying details and posting a link straight away. Requiring some back and forth communication from others just to do something for you doesn't sound like a good strategy for your problem.</comment>


37% of people commute by bike in Copenhagen thanks to this infrastructure - <AUTHOR> http://www.streetfilms.org/copenhagen%E2%80%99s-climate-friendly-bike-friendly-streets/

<comment><USER2> My my all the hating on bikes here. What gives? Have any of you actually commuted on a decent bike-- not one of the cheap $300 Walmart ones? It's glorious.

Is it wrong for Denmark to impose such a high tax? There's probably better economic means to accomplish the task. But the hating on the bike counter? Now that's just silly.

If you're in SF South Bay, there are plenty of low-traffic roads where you will beat the cars back home and be much, _much_ less stressed out from not needing to jockey in traffic-- at least if you could give up your prejudice for a moment. It also does your burn rate well for those of you doing startups.

<comment><USER3> I commute on a bike that's several levels _below_ a cheap $300 Walmart one -- and it's glorious. Every day, I get to work in a better mood than when I left home. I defy _anyone_ who drives to work to make the same claim honestly.

<comment><USER4> What are the temperatures like in your area? If I biked to work, at least 6 months out of the year I'd arrive a dripping, sweaty mess.

<comment><USER3> Northeastern rustbelt city. Hot and muggy in the summer, freezing cold in the winter (it's raining today but last Thursday and Friday were baltic), soggy the rest of the year.

Oh, yeah: and hilly. And there are almost no bike lanes.

</comment></comment></comment></comment><comment><USER5> I'll bet the 200% tax on car purchases helps to encourage bike commuting: <[http://wallstreetpit.com/12684-denmarks-200-pecent-car- tax-c...](http://wallstreetpit.com/12684-denmarks-200-pecent-car-tax-crazy- and-crazier>);

<comment><USER6> Indeed. And the result is that our car-fleet is one of the oldest, least environmentally friendly and least safe in western Europe.

<comment><USER7> Sounds like relying more on a gas tax would have been the better way to go. Distortionary taxes really need to be careful they are distortionary in the desired way.

<comment><USER6> Well, we have that too, and that also distorts.

A family with both parents working, living economically ie. not in an urban center, needs to drive a car to make ends meet. You can't do shopping for a family, and definitely not in economical sizes, on a bike or in a bus. They are hit hard by high gas costs, while a well-off urban professional takes his SUV to go skiing in Italy because it's still cheaper than flying+renting a car when he gets there.

<comment><USER8> You need a pretty big family before doing shopping by bus is not feasible.

I'm 34, Norwegian, have lived most of my life in Norway and England, and have no drivers license. Never learned to drive, because I've never felt the need to.

I do the family shopping for my small family of 3 on my commute home. I rarely need to pick anything up more than 2-3 times a week, and usually I only need one "big" round of shopping per week. It's never so much that I can't take it with me on the train, then walk to the bus stop and take it with me on the bus, _in addition_ to my fairly heavy bag of gym shoes + clothes. If we had another child or two I might end up going to the shops once more a week, or my wife might end up having to help out with the shopping more often.

While I might've saved a little bit here and there on buying larger quantities, not having the cost of car makes up for it many times over.

For that matter, not having a car saves us so much that we can easily afford delivery charger and/or taking a cab back if we ever want to do really large amounts of shopping, and still save money.

In other words: Apart from a really small number of people that live in so rural areas that they are not properly served by public transport (I'm talking about Europe here) _and_ are too far away to walk, it's not about needs but about perceived convenience.

But I don't even want a car. Apart from the cost, there's all the hassle of keeping it in a decent condition. I'd rather just pay for the service on the rare occasions I need it. Though I may consider getting a drivers license to at least have the option of renting a driverless car now and again.

</comment></comment></comment></comment></comment><comment><USER9> The difference between Denmark and the US is that the US would _never_ implement cycle infrastructure that could possibly increase travel times for cars. Denmark is willing to reduce the convenience of roads for motor vehicles, and that makes for a vastly better cycling experience. (Actually, cycling is fine in the US, but you have to be brave when you are just starting out. Copenhagen has designed in features that makes the roads very newbie- cyclist-friendly, so people don't get scared off the first time they ride on the street.)

Anyway, if the US ever wants to see cycling adopted by the average person and not only people who have already made the decision to commit, we need to: reduce the speed-limit in city centers to 20mph; have bicycle-only light timings; and start selling bicycles that are useful, not just "cool looking".

My guess is that this will not happen in my lifetime.

<comment><USER10> > cycling is fine in the US

My ER doctor friend says urban cycling is idiotic.

I do it all the time but you're kidding yourself if you don't realize it is extremely dangerous.

The more important issue in the US regarding bikes is the lack of density. It's simply not feasible to bike the kinds of distances most people need to go.

<comment><USER9> _My ER doctor friend says urban cycling is idiotic._

A friend of yours said something, so it must be true...

Most accidents are due to people driving their bicycles unsafely. If you drive safely, urban cycling is not dangerous. If you drive like a maniac and disregard traffic controls (running lights, riding on the sidewalk, going the wrong direction, etc.), then yeah... it's dangerous. Just like it would be as a pedestrian or motorist.

In aggregate, cycling is not significantly more dangerous than any other activity: <http://bicycleuniverse.info/transpo/almanac-safety.html>

(Despite this, I am in favor of laws and regulations that make the roads less dangerous. Cars should not go faster than bicycles in cities. If you need to get somewhere fast, use rapid transit.)

<comment><USER11> > If you need to get somewhere fast, use rapid transit.

I have a hard time believing anyone in the US (except maybe New York) could say this with a straight face. Where do you live that rapid transit is so rapid?

<comment><USER9> Chicago. It takes me about 15 minutes to get to work on the train. Driving would probably take a bit longer, and would cost about $40/day. (Not including the cost to get a car and a driver's license; neither of which I have.)

</comment></comment></comment></comment></comment><comment><USER12> Nice cycling lanes and impressive statistics, but I don't get the impression that bicycles are as ubiquitous (yet) as they are in Amsterdam.

I wonder how they handle bicycle parking in Copenhagen, because that's a real problem in most Dutch cities. Especially those cargo bikes take a lot of space.

<comment><USER13> This is a great photo essay on bicycles in Amsterdam:

<http://www.ski-epic.com/amsterdam_bicycles/>

<comment><USER14> It's a bit weird how the short description of just about every photo ends with "... on a bicycle, in Amsterdam" or some close equivalent. Either the author is just completely freaked out that all these things happen OMG ON A BICYCLE IN FREAKING AMSTERDAM, or it's some sort of attempt at SEO, hoping that Google will place this page really highly for people searching for <<<bicycle amsterdam>>>.

If it's the latter then it seems to have worked; the page is the top organic Google result for those words, at least for me at the moment. I do hope that _isn't_ because of the clunkily repetititititive writing style.

</comment></comment></comment><comment><USER15> It's thanks to a lot more than just that infrastructure.

      1 taxes, cost of fuel
      2 culture (USA views bikes as for kids and tree-huggers)
      3 density of urban areas
      4 layout/zoning of urban areas (i.e. no ring of suburbia, shopping/strip malls around cities)
      5 probably others that I'm not aware of

The infrastructure doesn't work without 3 and 4, and probably doesn't work without 2.

<comment><USER16> The Mandatory Helmets also help to discourage bikes.

<comment><USER17> In the same way that everyone stopped driving their cars when seatbelts became mandatory?

<comment><USER16> No, in the same way that people will not start smoking if they have to use mandatory safety goggles. Of course this kind of method depends on two things:

1) how critical the activity is to people's lives (cycling: low, driving: high)

2) how funny you look with the safety item on (...)

</comment></comment></comment></comment><comment><USER18> After living in Copenhagen for 1,5 years I think I can add some info to this.

First of all, biking is the only reasonable way to commute in Copenhagen. Car traffic is big, but the most discouraging factor for me is the parking fees. During business hours, paring in the red zone, which is the city centre, is $5.50 per hour. And you have to be lucky to find a spot, and you still have to walk a significant distance to your destination. Whereas when you take your bike, you can leave it just outside the place you're going to (bike parking spots are everywhere).

There is a lot of people who live in Greater Copenhagen (Cph and cities around it) and commute to the centre by S-trains. This creates the problem of having to either pay extra for taking your bike on the train, or having one bike for home - train station and one for train station - work. The attempted solution for that was the city bikes system, free bikes you could rent, in theory everywhere. In practice however, these bikes are nowhere to be found or somehow broken.

So, what Copenhagen really needs is a decent bike sharing system. A friend of mine conducted a survey for a university project, and there is a huge interest in this kind of system. People would gladly pay a monthly fee to be able to get off a train and pick up a bike that's waiting right next to the station.

I see this as a big idea for many cities. More people would use bikes if they didn't have to actually own and maintain them, and care about theft. Someone make this into a startup please? :)

<comment><USER19> This already exists in the Netherlands, called the "OV-fiets" (public transport bicycle). You take a subscription (€10 a year), and then using a card you can rent a bicycle at almost any railstation for a little less than €3 for 18 hours. You can rent them longer if you want, and even return them to a different place than you got them from (for a fee).

Most of these places have manned bicycle storage facilities where you can rent them, but they also have some in automated lockers in lesser frequented locations. They're now also starting to put these in commuter parking spots at edges of cities.

</comment></comment><comment><USER20> I think a good way to bootstrap the stuff is the rental bike program like Lyon then Paris. They just put a lot of bikes at once in the city.

There's a lot of friction in the beginning (you know how car drivers always think pedestrian and bikes are dangerous, when the kinetic energy computation tell another story) but I think it's efficient.

But you need strong political will, I mean you'll have stories dead bikers in the news, you'll have to cope with the bike-unaware traffic rules and stuff like that.

</comment><comment><USER6> First, the über-fancyness reported is purely COP-15 show-off and nothing else. The bike-counter, for an example, serves no practical purpose. I don't even know what the reported LEDS are.

It's true that it's very nice to be a biker in Copenhagen, but I believe that it's a case of chicken-and-egg: I think most of the amenities are there because Danes enjoy biking in large numbers, and not the other way around.

<comment><USER21> Fairly certain the LEDs he was talking about were the turn-lane indicators, that warn a turning car if a bicyclist is on the way. That's kind of amazing, and would potentially do wonders in a city like NYC. We already have some separated bicycle lanes (with obstructions between the cyclers and the autos), separate bike traffic lights, but only in a very few spots (8th avenue has a large stretch).

One of these days I'll get one.. :)

Also, if you watch the video he mentions that it's taken thirty some odd years to build out this infrastructure, and that it used to be a much more car- centric city.

<comment><USER22> The other thing that NYC would do well to implement was the so-called "green highway". I bike to work every day and find that our separated bike lanes have longer and more frequent red lights than the lanes given to cars (we have a red light when they have a green light + left turn arrow). Most of the people who bike frequently in the city actually avoid the separated bike lanes because of the poor traffic light timing.

<comment><USER23> Yes, that I think is the best of the social engineering ideas presented in that video, its also one of the easiest for the city to implement in terms of infrastructure.

You would make a lot of people mad by doing it though.

<comment><USER21> There's already so much bicycle-hate in this city (mainly towards couriers: <http://www.youtube.com/watch?v=NmHRnA780WM> ), that I can imagine it getting out of hand.

Most of the people it would effect are cab drivers/drivers-for-hire and delivery trucks/vans. Everyone else who drives daily in the city is, imho, an asshole ;)

</comment></comment></comment></comment></comment><comment><USER24> The fact that they live within biking distance of where they want to go has nothing to do with it....

<comment><USER18> Not really true. People can take their bikes on S-trains, which come from >20km from the centre.

<comment><USER24> CalTrain carries bikes too.

</comment></comment></comment><comment><USER19> The claim for having the busiest bicycle street of the west is frankly ridiculous. The guy must never have been to the Netherlands. I myself live in Utrecht, and we have streets that see more than 2000 bicycles at 8:30am, let alone at 11am (yes, even on weekends).

</comment><comment><USER25> [http://www.oregonlive.com/news/index.ssf/2009/10/portland_se...](http://www.oregonlive.com/news/index.ssf/2009/10/portland_seeks_public_input_fo.html)

</comment><comment><USER26> To see the number 37 and the word Copenhagen in one headline, makes me think I should get real.</comment>


Fearless Security: Memory Safety - <AUTHOR> https://hacks.mozilla.org/2019/01/fearless-security-memory-safety/ <comment><USER2> When talking about Garbage Collection they claim that _" Even languages with highly optimized garbage collectors can't match the performance of non-GC'd languages"_ and link to this paper: [http://greenlab.di.uminho.pt/wp- content/uploads/2017/09/pape...](http://greenlab.di.uminho.pt/wp- content/uploads/2017/09/paperSLE.pdf) However I cannot see where this paper supports the assertion (although Rust comes out well).

The particular problem is that malloc/free is not free of charge. Different allocators have complex internal implementations, plus you lose easy sharing of complex structures and compaction. So if you're using a GC you probably program in a different way, eg using more shared immutable structures, exploiting the advantages of GC.

Edit: A bit later they brush off this old favourite for GC-haters: [https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf](https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf) claiming that GC requires 5x as much memory. The problem with this paper is it assumes that malloc/free is cost-free and instantaneous, and that your programmer always calls free at the exact moment that the memory is no longer needed, both of which are extremely unrealistic.

<comment><USER3> _> The particular problem is that malloc/free is not free of charge. [...] The problem with this paper is it assumes that malloc/free is cost-free and instantaneous,_

I think I get that you're trying to explain how GC overhead is overstated and malloc()/free() is understated but your angle about "malloc not being free of charge" it isn't really the evidence you want to use.

As analogy, we can see that a Lamborghini is faster than a Hyundai. Let's say we state that the performance comparison is flawed because it it still takes the Lamborghini a _non-zero amount of time_ to accelerate to 60 mph (or 100 km/hr) and Lamborghini is _still consuming gasoline_. While the cost datapoints are _true_ , it still doesn't change the macro observation that the Hyundai is slower.

Also, you're misrepresenting the 2nd paper you cited. The authors do mention "overhead" of malloc. They do _not_ assume that malloc is "cost-free" on page 4:

 _> 3.2 malloc Overhead - When using allocators implemented in C, the oracular memory manager invokes allocation and deallocation functions through the Jikes VM SysCall foreign function call interface. While not free, these calls do not incur as much overhead as JNI invocations. Their total cost is just 11 instructions: six loads and stores, three registerto-register moves, one load- immediate, and one jump. This cost is similar to that of invoking memory operations in C and C++, where malloc and free are functions defined in an external library (e.g., libc.so)._

In other words, even if malloc/free is _not instantaneous and not cost-free_ , it can still be faster than GC. Neither paper's conclusions depend on malloc/free taking zero amounts of time or zero cpu instructions. If the papers are flawed, you have to explain it using different logic.

<comment><USER4> > >3.2 malloc Overhead - When using allocators implemented in C...

That's not even about malloc overhead, it's about the overhead of just _calling_ C malloc. So actual malloc overhead is on top of that.

Malloc and free have pretty unpredictable runtime over time, once a lot of allocations and deallocations have been performed. That's why you don't use either in latency sensitive code, like with realtime requirements.

> In other words, even if malloc/free is not instantaneous and not cost-free, > it can still be faster than GC.

Whoah, faster than GC in _what_ regard? GC will probably win the throughput race, or _average_ latency. Manual allocation will likely win the jitter race, lower latency standard deviation.

(I write low level code in C/C++, including kernel drivers and bare metal firmware with hard realtime requirements. Hopefully in the future in Rust or some other memory _and_ concurrency safe language.)

<comment><USER3> _> Malloc and free have pretty unpredictable runtime over time, _

Yes, that's another _true_ statement about malloc but it also doesn't matter to the particular point I'm making. To continue your _correct & true_ statements of malloc, we can add:

\- malloc has to search the freelist; GC can be just a bump allocation which is faster

\- malloc leads to fragmented memory; GC can reorganize and reconsolidate

\- malloc doesn't have extra intelligence to assign pointers to shared memory structures (e.g. Java string pool stores identical strings only once based on hashes)

\- ... a dozen other true statements about malloc

All those true statements (which most can agree on) isn't the misunderstanding. The issue is _misusing_ those true statements as some type of convincing evidence to explain the papers' flaws. For example:

 _> Whoah, faster than GC in what regard?_

Well, we can just use the _total runtime_ of the the 2 papers benchmarks where there were lots of memory operations. (In other words, we can acknowledge that performance has multiple dimensions/axis but we can also look at the simple measurement of _total wall clock time_ of benchmark code that doesn't do database access or floating point calculations.)

 _The C /C++ programs ran faster and took up less memory._

Ok, were there flaws in the benchmarks? Then lets explain _the specific flaws_.

Yes, I can say _" malloc runtime is unpredictable"_ but that true statement doesn't actually explain anything about GC running slower than malloc/free in the papers. We can also say that _" malloc is not cost free"_ as another _true_ statement -- but that also doesn't actually explain the GC's longer elapsed time.

See the problem with those attempted explanations? They're all non-sequiturs.

<comment><USER4> > Well, we can just use the total runtime of the the 2 papers benchmarks where > there were lots of memory operations. (In other words, we can acknowledge > that performance has multiple dimensions/axis but we can also look at the > simple measurement of total wall clock time of benchmark code that doesn't > do database access or floating point calculations.)

...

> See the problem with those attempted explanations? They're all non- > sequiturs.

I'm comparing GC vs manual memory management.

You (or the papers) are comparing different implementations of programs in different languages. That might be great for practical considerations for choosing implementation language, but is pointless when comparing those two different memory management strategies. Apples and oranges.

EDIT: I feel "Quantifying the Performance of Garbage Collection vs. Explicit Memory Management" paper is a bit dishonest. From the paper:

> The culprit here is garbage collection activity, which visits far more pages > than the application itself [61]. As allocation intensity increases, the > number of major garbage collections also increases. Since each garbage > collection is likely to visit _pages that have been evicted_ , the > performance gap between the garbage collectors and explicit memory managers > grows as the number of major collections increases.

 _Pages got evicted_ – so their heap ran out of physical RAM and started swapping to disk. Wow.

Yeah, GC uses much more RAM, that's a well known downside. Setting the benchmark up in such a way that causes the system to start swapping is not a fair way to compare GC and manual allocation throughput.

<comment><USER3> _> You (or the papers) are comparing different implementations of programs in different languages._

Fyi... the 2nd paper is using the same language of Java. It just compares different allocation strategies: explicit vs GC. (I think that paper is written in a confusing way.)

My original point back to op (rwmj) was that the computer scientists were quite aware that malloc had a non-zero cost. And pointing that out really doesn't challenge the paper's findings.

<comment><USER4> Yeah, and the second paper said their GC scenario system was _swapping to disk_. Please read my edit to the previous comment.

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> For completeness sake, there are C programs that never allocate memory dynamically, using press-allocated variables only. Your microwave likely runs one.

There are also programs that allocate but never we-allocate memory. They are fast-terminating programs, ranging from a CLI utility to onboard software that controls a surface-to-air rocket.

But many programs still need more complex memory management done safely.

<comment><USER6> Buffer overflow without any dynamic allocation:

#include <string.h>

#include <stdio.h>

int main() {

char hello[5];

strcpy(hello, "hello");

printf("%s\n", hello);

}

(gcc warns about, interestingly clang does not)

<comment><USER7> Rust recently had an integer overflow in str::repeat permitting a buffer overflow. It was a classic bug, the kind that gave C a bad reputation. And the error(s) in arithmetic occurred _outside_ any unsafe block.

If we want to be pedantic, all this talk of "fearless" wrt Rust is dangerous hyperbole. Once you move past juggling scalar values things get dicey, especially in C but also in so-called "safe" languages like Rust. And that, I think, was the previous poster's point--as you move away from dynamic allocation you tend to move toward using scalar (fixed-sized) objects.

One of the original points of emphasis of Rust was to favor scalar values rather than pointers and even references. To a limited but useful extent you can mimic this in C. Rust examples that simply use Vec miss the point--1) the str::repeat bug overflowed a Vec, and 2) just because C doesn't come with a built-in Vec doesn't mean you can't write one or use one.

<comment><USER8> > Rust recently had an integer overflow in str::repeat permitting a buffer > overflow.

In case someone is interested of the details, like I was: [http://cve.mitre.org/cgi- bin/cvename.cgi?name=CVE-2018-10008...](http://cve.mitre.org/cgi- bin/cvename.cgi?name=CVE-2018-1000810)

</comment></comment></comment></comment><comment><USER9> "Another type of problem that can appear is memory leakage... This is a memory-related problem, but one that can't be addressed by programming languages."

[https://www.fos.kuis.kyoto-u.ac.jp/~tanki/papers/memoryleak....](https://www.fos.kuis.kyoto-u.ac.jp/~tanki/papers/memoryleak.pdf)

Well, that took about a minute in DuckDuckGo. :) Key words were "memory leaks" and "type system." For those wanting to find CompSci, adding type system in quotes to a property is a reliable way to find language work on that property. The word language can help, too, but the wording in PDF's varies on that more.

</comment><comment><USER10> Not bad but a little bit of a publicity stunt.

A major source of vulnerabilities is (still) the Javascript engine and that's (still) written in C++.

Even worse, as far as I know, Mozilla has no plans to rewrite even parts of Spidermonkey in Rust.

For some recent examples:

[https://usn.ubuntu.com/3688-1/](https://usn.ubuntu.com/3688-1/)

[https://usn.ubuntu.com/3749-1/](https://usn.ubuntu.com/3749-1/)

<comment><USER11> A JS engine is a high-risk, high-reward problem for Rust. High-reward because JS engines are, to your point, a major source of vulnerabilities; high-risk because JS-engine theory is rather outside of Rust's wheelhouse.

One class of vulnerabilities in JS engines is use-after-move. A raw pointer is extracted, an allocating function is called (triggering a GC), then the raw pointer is used, pointing into nowhere. It's awkward to express in Rust that a function may modify state inaccessible from its parameters.

A second class of vulnerabilities is type-confusion. A value is resolved to (a pointer to) some concrete type, but some later code mutates the value. Now the concrete type is wrong. Again this possibility is awkward to express in Rust.

The problem is complicated by the NaN-boxing and JIT aspects of JS engines, which interfere with Rust's tree-ownership dreams.

People smarter and way better at Rust than myself are working on it; I'm excited by the prospect of novel solutions that can defeat entire classes of problems.

<comment><USER12> I'm curious what proportion of vulnerabilities in JS engines are due to mis- generated JIT code vs direct errors in their compiled code. Rust allows you to express some nice properties not always directly related to memory safety (e.g. checked consumption, convenient and safe ADTs), but unless there is a novel application of these facilities to the structure of a JIT engine it won't help a ton with the former kind of vulnerabilities.

I'm excited to see a practical programming language that implements full dependent typing; languages like Idris are actually really good at dealing with precisely the kinds of situations you mention.

<comment><USER11> JS engines have many parts implemented natively, which may be called from JS, and in turn call back into JS. An example is CVE-2015-6764: this grabs an array length, which quickly becomes stale, because accessing one of the array's elements invokes a custom toJSON which in turn modifies the array's length.

This feels like a hopeless problem; can any of Rust's powers be brought to bear here? Could Idris?

<comment><USER12> F* is probably the best equipped at the moment to deal with situations like that CVE at the moment, since its library has a concept of heaps. Basically, any function that can access or modify the "heap" (which in F* is just a set of pointers that are guaranteed to point to a value and not alias any others outside of the same heap) must specify what properties of the state of the heap must be true at entry, and what properties are true afterwards. So in pseudo-types (, the functions for accessing a JavaScript array would be something along the lines of

        fn arrayLength(x: JSArray*) -> n: uint (requires nothing) (ensures length of x = n, changes nothing)
        fn callToJson(x: JSValue*) -> JSValue* (requires nothing) (ensures nothing)
        fn arrayAccess(x: JSArray*, m: uint) -> JSValue* (requires length of x > m) (changes nothing)

(NB: F* syntax doesn't look much like this, but I'm guessing this will be readable to more people on HN)

The stuff in parentheses after each function type are the preconditions and post-conditions respectively. So if you do something like:

        let x = arrayLength(someArray)
        for i in range(x) {
          let element = arrayAccess(x-1)
        }

It will typecheck just fine. But if you add the call to toJSON:

        let x = arrayLength(someArray)
        for i in range(x) {
          let element = arrayAccess(x-1)
          let transformed = callToJson(element)
          // ERROR: (requires length of x > m) not satisfied for all runs of loop body
        }

Since callToJson cannot ensure any property of the heap after it runs. In this way you can elide range checks when needed for performance without worrying that you've sacrificed safety.

Covering all the cases a JS engine would need without adding 10 million lines of proofs to the size of SpiderMonkey is still an open problem, but this general approach (known as Hoare Logic[1]) is very enticing, and the type systems that languages like Idris and F* have are definitely the closest to realizing it in more places. There are real software engineering efforts using descendants of Hoare logic like TLA+ (notably Amazon IIRC), but it's rare to see it even in huge projects like browsers.

It's also critical to note that the heap concept of F* is not a totally fixed part of the language; most of the specification of how heaps work are actually in the standard library. That level of flexibility is what I think makes these languages likely to become capable of tackling these problems: something like a JS engine or any optimizing compiler is exactly the kind of place where being able to come up with your own type-level verification model is worth the effort.

[1]: [https://en.wikipedia.org/wiki/Hoare_logic](https://en.wikipedia.org/wiki/Hoare_logic)

</comment></comment></comment></comment></comment><comment><USER13> _" Some languages (like C) require programmers to manually manage memory by specifying when to allocate resources, how much to allocate, and when to free the resources."_

This is not required of programmers in C, because the programmer could choose to delegate memory management to a memory management library, such as the Boehm-Demers-Weiser conservative garbage collector. [1]

[1] - [http://www.hboehm.info/gc/](http://www.hboehm.info/gc/)

<comment><USER14> Conservative garbage collection like Boehm inevitably leads to memory leaks in long running applications. It's awesome for some use cases but isn't a complete solution by any means.

<comment><USER15> Wrong. Only if the system failed to identify a root, which is a grave developers mistake, but in the general case boehm-gc does not generate any leaks.

Unlike manual memory collection which inevitably leads to memory leaks.

<comment><USER16> Failing to identify a root would cause the GC to free too much memory. Memory leaks happen when too little memory is freed. Boehm GC is called conservative because it can't distinguish pointers from other memory content, so it will determine some allocations to be reachable even if there's no pointer to them, because some random integer looks like a pointer into that allocation.

<comment><USER15> I see, that's what you meant. You are right. You need to use boehmgc in precise mode, which is not the default. You need to tag your pointers. Also use incremental mode for shorter pause times.

</comment></comment></comment></comment></comment><comment><USER17> In related news, the C/C++ development community is finally catching up to what Java has been providing for over 20 years.

<comment><USER18> What is it that the C/C++ development community is catching up to?

(And also, I'm not convinced that programming languages should be treated as having their own isolated developer communities, considering there is often a lot of overlap. Are we talking individual users? Companies? Language designers? Etc.)

<comment><USER19> Good support for multi-core programming comparable to what java.lang.concurrent, language thread and network async IO offer.

C++11 introduced std::thread, with a couple of issues retified in later revisions, and apparently executors just failed C++20, delaying the introduction of a major part of async networking.

Language safety as well.

For me, in spite of the safety improvements in C++, I see the language being tailored for specific niches and no longer a full stack language, similar to how it is handled on modern desktop and mobile OSes.

And C will never catch up in security.</comment></comment></comment>


Physicists investigate why matter and antimatter are not mirror images - <AUTHOR> https://www.economist.com/science-and-technology/2018/09/22/physicists-investigate-why-matter-and-antimatter-are-not-mirror-images <comment><USER3> Interesting. I was just talking with a friend about that this weekend. He's working on another experiment, the Deep Underground Neutrino Experiment (DUNE) which is investigating this question, among others. They're shooting a neutrino beam from Fermi Lab in Chicago to a detector deep underground in South Dakota, allowing them to measure several characteristic parameters of these neutrinos. One of them, delta_cp, will give insight into the question of the matter-antimatter imbalance[0].

As just a lowly software developer, it's quite amazing to me to see what cutting edge physicists are up to. The engineering scale of these experiments is mind boggling.

[0] [https://en.wikipedia.org/wiki/CP_violation#CP_violation_and_...](https://en.wikipedia.org/wiki/CP_violation#CP_violation_and_the_matter%E2%80%93antimatter_imbalance)

<comment><USER4> Since you mentioned it I'll plug it (simply because I think it's cool): FermiLab has a lot of public events they host as well as various interesting lectures [http://news.fnal.gov/newsroom/public- events/](http://news.fnal.gov/newsroom/public-events/)

It's in Batavia, about an hour's drive outside Chicago.

<comment><USER5> Are there any good podcasts offering behind the scenes perspectives on experiments at this level?

</comment></comment></comment><comment><USER6> Article doesn't match title. They're studying gravity's pull on antimatter.

<comment><USER7> Actually it does. The article intro starts with the fundamental question (why is there an apparent imbalance in the amount of matter/antimatter), then says that one experiment is this gravity one. It returns at the end to the point that the standard model doesn't predict a difference, but then again the standard model doesn't predict the mismatch either.

</comment></comment><comment><USER8> Is it possible that if they were, they would annihilate each other, so you couldn't live in an area where both are present, and so we are necessarily born in a place where there's much more of only one type? The antimatter might be outside of the observable universe, safely away from interacting with us for the foreseeable future.

<comment><USER6> There was a short story about an antimatter alien who visited Earth. It shook hands with a human and both were annihilated.

<comment><USER8> Wouldn't it already be annihilated by air particles though :)

<comment><USER6> It was very early science fiction. And yes it would.

<comment><USER9> Wouldn't it already be annihilated by photons from the sun?

</comment></comment></comment></comment></comment><comment><USER10> Do we really _know_ for sure that there is more matter than antimatter in the universe?

All we collect from distant galaxies is light, which, as far as I know, interacts with antimatter in the exact same way as with matter. Do we see any gamma-ray producing zones in intergalactic space that might form the boundaries between "matter-zones" and "antimatter-zones"?

<comment><USER11> You're spot on with the gamma producing zones. We don't see any of those, and that's why we don't think any galaxies are made of antimatter.

[https://www.scientificamerican.com/article/how-do-we-know- th...](https://www.scientificamerican.com/article/how-do-we-know-that-dista/)

<comment><USER12> I thought there were signs of gamma radiation surrounding galaxies. Perhaps the gas filled void between galaxies is antimatter while the galaxies are matter. Perhaps antimatter is repelled by both types and regular matter is attracted to both types. This might lead to a gaseous cloud pushing things apart and clumps of regular matter. It would also allow some configurations to accelerate and violate conservation of momentum, so it doesn't seem likely.

To me there are more questions than "does antimatter fall up?" There are 4 interactions to test.

</comment></comment></comment><comment><USER13> I've always wondered about this, perhaps someone who understands this subject could explain.

Say matter and antimatter were created in roughly equal proportions then some collided to create energy. Couldn't then this energy coalesce back to regular matter through the mass-energy equivalence? E=mc^2? Repeat this a bit and you'd end up with more matter than antimatter.

As I said, this is so simple there must be an easy argument against it but I've never heard the idea addressed.

<comment><USER14> realize,

It's not _obviously_ impossible, but in fact this is never observed - <USER2> particle is _ever_ created without a corresponding antiparticle. (The corresponding laws are "lepton number conservation" and "baryon number conservation" \- basically, the total number of electrons[1] minus the total number of anti-electrons[2] remains constant, and so does the total number of quarks minus antiquarks. All of the interactions of the Standard Model respect these.[3][4]

There are various beyond-standard-model theories that allow breaking baryon and lepton number conservation _individually_ , with the combined number of (baryons - leptons) being a conserved quantity instead; but they also almost all predict that protons should be slightly unstable (because being able to go from _[Exotic Mystery Particle]_ to baryons + leptons means you should also be able to go from baryons (like the proton) to _[Exotic Mystery Particle]_ and leptons) but we've looked _really really hard_ for evidence of extremely rare proton decays and have yet to find any.

[1](plus muons, and tauons, and the three corresponding flavors of neutrinos)

[2](plus anti-muons, and anti-tauons, and anti-neutrinos)

[3]Even the observed violations of matter-antimatter asymmetry ("CP violation") still respect these conserved quantities; they just involve things like anti-kaons decaying slightly but measurably faster than kaons.

[4]On the other hand, there's no particular reason to expect _gravity_ to respect these; For instance, we think black holes can consume matter, and then convert it to energy in the form of Hawking radiation as they slowly decay, without having to bother with eating an equal quantity of antimatter. But honestly we're just guessing on that front.

<comment><USER15> > For instance, we think black holes can consume matter, and then convert it > to energy in the form of Hawking radiation as they slowly decay, without > having to bother with eating an equal quantity of antimatter.

> we're just guessing

Black holes (BHs) are not a very realistic candidate for solving baryon asymmetry. Where's the antimatter outside the horizon of a modern (as in after structure formation) astrophysical BH? If it's not there, it can't fall in. This is really hard to work around even for early direct-collapse super- massive BHs; hierarchical growth is already essentially ruled out. Worse, how do you keep signatures of annihilations out of the region near the BHs, including the accretion material and any jets?

Or are you expecting primordial BHs to couple differently to baryons and their antis? How do you suppress that difference in the weak field limit, or more generally after first light? (And in either case, how do you make sure that virtually all of the antimatter is locked up in BHs?) Essentially you keep coming back to having the stress-energy already significantly (really, almost entirely) segregated into particles and their antis, around the time of gravitational collapse, or you depart dramatically from General Relativity in a regime in which it is already supported by evidence.

Finally, where are you hiding all these black holes, whenever they formed? If only BHs break baryon symmetry, the contribution to \Omega implies a lot of lensing. (Speculating in the direction of a dust of tiny remnants or the like is also hard work, and usually involves beyond-the-standard-model new physics anyway, although there is a small literature that involves operators like \partial_{\mu}F(R)J^{\mu}, where J^{\mu} is the baryon or lepton current, and R is the curvature scalar or the Riemann tensor (R_{\mu\nu\rho\sigma}R^{\mu\nu\rho\sigma}) or a more complex term, and afaik none of these model-builders take backreaction into account yet.)

<comment><USER16> > Black holes (BHs) are not a very realistic candidate for solving baryon > asymmetry.

I'm reasonably certain grandparent wasn't proposing this as a theory, just using it as a simple gedankenexperiment to show that gravity isn't inherently respectful of charge conservation.

<comment><USER14> Bingo.

Well, not quite - black holes _would_ be respective of charge conservation! A black hole only has three properties, in our current understanding of general relativity - but "electrical charge" is one of those properties.

But there's nothing that stops it, say, eating protons and spitting out positrons later.

<comment><USER10> Do you mind if I ask you some questions about this?

I always have trouble picturing how, dynamically, a charge inside an event horizon is supposed to be able to propagate an electric field outside the event horizon of a black-hole. (retarded vector potential travels from a charge along light-paths to another point in space-time. There isn't any way for the influence of a point charge to get out?)

Perhaps some other related questions too: Charge and current density is a 4-vector in SR, which transforms along with all the other 4-vectors (momentum- energy 4-vector, etc). In a situation where the effective mass of an object _reversibly_ lowered to the event-horizon (slowly moved relative to the event horizon with small velocity) goes to zero (all the mass energy ends up somewhere else) - wouldn't the effective charge density from a non-infalling external observer's perspective also be going to zero?

If we're just drawing a box around a black-hole and declaring that charge is conserved, we would have as much/little reason to declare any other conservation also holds?

<comment><USER15> These are good questions! You might consider taking them to a forum where you'll get a more rigorous answer though. :D

Fully classically, the field lines point to the sources; they get "stuck" to the horizon as the source crosses. To a naive outside distant observer for whom the horizon subtends a small angle of the sky, so does each source. When thinking about collapsing charged matter forming a new black hole, substitute a spherically symmetric shell and shrink its area, while keeping the charge and mass constant and uniformly distributed on the shell -- the electric field and gravitational field outside the shell then both follow gauss-laws, so even without a horizon, observers outside the shell at a large distance (such that the shell looks virtually pointlike) cannot get the full information about the shell using only local measurements, including whether the shell is inside or outside a horizon.

Semiclassically, one can use virtual photons which aren't as restricted as real matter, especially in that the black hole horizon is not necessarily a trapping surface for them. Typically one sets up the black hole as a background that has already determined the relevant quantum fields, and then introduces a test particle onto that background. If the test particle radiates a photon, the black hole will only react once the photon enters the horizon; unless and until that happens, the background is kept constant. (Hawking introduces negative energy particles in his formalism precisely to keep the background always constant.) Changing the background is tricky, but never involves real particles crossing from the interior of the horizon to the exterior.

> we would have as much/little reason to declare any other conservation also > holds

Sure, no-hair as a _theorem_ (rather than as a principle) only tells you that given classical vacuum, Maxwell's electromagnetism (in tensor form), and an eternal black hole metric, spacetime and all its contents are totally determined everywhere by a small handful of parameters. As a principle it suggests that perturbing that setup (e.g. by adding a source outside the horizon) does not lead to wildly inaccurate results.

I'm sorry that I don't understand what it is that you're asking in your second-last paragraph. There is a body of literature on black hole "mining" (it's a common thought-experiment when trying to distinguish between general relativity an alternative theory, especially a quantum one) that maybe touches on what you're curious about.

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> Couldn't open the article. Do they mean literally mirror images (like geometrically mirrored in a plane)?

This makes me wonder, in chemistry you have the concept of chirality. What would happen if you'd literally mirror a non-chiral molecule (down to the quark level)?

<comment><USER14> >Do they mean literally mirror images

Almost! To be more specific, the laws of physics are CP-symmetric[1] - if you take any interaction involving matter and/or antimatter, and you swap all the positively charged particles with their negatively charged antiparticles and vice versa, and then you invert the coordinate system (swapping left-handed and right-handed chirality, aka "literally mirror image") it should now behave exactly the same.

Basically, antimatter is matter with the charges reversed _and_ the handedness mirrored.

[1]techically it's only CPT symmetric - you're only _guaranteed_ perfect symmetry under simultaneous reversal of charge, parity (handedness), _and_ time. But almost all processes (anything mediated by gravity, electromagnetism, or - as far as we can tell - the strong nuclear force) are perfectly CP-symmetric; As far as we can tell, CP symmetry violation only shows up in rare scenarios involving the weak nuclear force, where some particles can take slightly longer to decay than their antiparticles.

<comment><USER17> Thanks!

This makes me wonder, since we've obviously never actually mirrored any particle, is there any chance that charge will (ultimately) also turn out to be a geometric concept? (By analogy to magnetism, where changing the orientation of the current flips the polarity of the magnetic effect).

<comment><USER14> Depending on what you mean by "geometric", maybe - there's been attempts at constructing theories where the electromagnetic field is also, like gravity, a product of spacetime geometry; these generally involve adding extra dimensions to give spacetime enough freedom to hold those behaviors, and then curling up the extra dimensions small enough to explain why we hadn't noticed them yet.

(String theory is one of the distant descendants of these attempts.)

<comment><USER18> This is probably referring to [https://en.wikipedia.org/wiki/Kaluza–Klein_theory](https://en.wikipedia.org/wiki/Kaluza–Klein_theory).</comment></comment></comment></comment></comment>


Some cool tips to make search in Google more effectively - <AUTHOR> http://savedelete.com/google-search-tips.html <comment><USER2> gr8 tips

</comment><comment><USER3> really cool</comment>


Broadband: other countries do it better, but how? - <AUTHOR> http://arstechnica.com/news.ars/post/20080511-broadband-other-countries-do-it-better-but-how.html

<comment><USER2> It just isn't economically viable to run fiber/copper out to areas below a certain population density. Particularly because those low density area also have less demand for broadband.

Also, why is it automatically assumed that more broadband is better? How much more productive is broadband going to make a farmer or a welder (over 56K or ISDN?).

This is just as bad as thinking more education is always better. A doctor with 20 years of school may be more productive than one with 14, but would a mechanic with 20 years of school be that much better than one with 14? (Note: I'm talking about formal in-school education. Both doctors and mechanics have considerable on-the-job training in addition to their schooling).

<comment><USER3> That's very short-sighted.

Broadband in a rural area means that the area is more appealing to business, leading to development of the area and economic improvement.

This can be seen happening in various European countries. Some of the farms outside of the city where I live have been able to convert some of their land into serviced offices, making them a pretty penny since broadband access was mandated.

</comment></comment><comment><USER4> This article is wrong. There exists a duopoly all over the US in broadband Internet - one can choose DSL or Cable - because every local municipality grants a local monopoly to one phone company and one cable company (and they usually choose one of the largest national companies in each case).

We need to break these monopolies and allow any company to build infrastructure. Then we will see competition increase and prices go down.

Not mentioned in the article is the UK, which has exactly the system I am proposing - one with almost no government regulation - and is at least on par with all the countries listed in the article, if not doing better. This example goes to show that socialist infrastructure and regulation is not the essential factor that makes broadband access better.

<comment><USER5> Broadband access in the UK is definitely not on par with the countries listed in the article.

<comment><USER6> So very true. The best you can get in the UK is about 24 Mbps down, and 1.3 Mbps up - and that is with ADSL. When it comes to cable, there is only really one operator and that is Virgin Media. When it was NTL it was really good: fast, reliable, no throttling and no monitoring. But when Virgin bought it, then everything went tits-up: throttling, unreliable and part of the phorm debacle. If I had my choice I would go for the Scandinavian or Japanese system, i.e. fast and relentless.

<comment><USER3> Yep, UK access isn't that great.

24Mbps down? Only if you're sitting directly on top of the exchange! From Be*, I get around 13-14Mbps down and 1.3Mbps up with the option to move to Annex M to increase my upload speed to around 2.3Mbps, for an equivalent (or greater) drop in download speed.

However, a very good thing about unbundling is the ability to combine several SDSL lines from different providers to give a leased-line-like connection for a fraction of the cost.

<comment><USER4> So maybe it's not that great (that's not what I had heard), but you have different providers!! That is at least a huge step up from what we have here. That is like music to the ears of an American. Here you pretty much have no choice except, Cable or DSL.</comment></comment></comment></comment></comment>


Announcing Beaker Browser 0.7 - <AUTHOR> https://pfrazee.github.io/blog/beaker-browser-0.7 <comment><USER2> Opera used to provide something that behaved something like this from the user's point of view. It never got much attention though and was eventually dropped.

</comment><comment><USER3> How easy is it to publish a site that is backwards compatible with existing browsers? I can't foresee a project like this gaining critical mass if it doesn't have seamless backwards compatibility with the traditional web.

<comment><USER4> You can use [https://github.com/beakerbrowser/dathttpd](https://github.com/beakerbrowser/dathttpd) to serve over p2p and http

<comment><USER3> Nice touch with the built-in support for LetsEncrypt!

</comment></comment></comment><comment><USER5> This isn't possible with an extension? Hard to download (and keep up-to-date) a version of Chrome. An extension would speed up mass adoption.

<comment><USER4> An extension wouldn't let us define a custom protocol. We get more freedom this way. FWIW, our meta goal is to successfully demonstrate with Beaker, then approach standards bodies.

</comment></comment><comment><USER6> This page looks... really bad on Firefox for Android. Content is barely readable.

<comment><USER4> Thanks for the heads up</comment></comment>