skysight-inc/HackerNews huggingface dataset:
Right. What Raymond is trying to say is that if the attacker is someone else (in your case, the attacker is the person getting the victim to use a specific long filename), then it's escalation and hence an issue. Otherwise his post would mean that even opening a bad Word doc isn't a security hole.

Thus, if you are trying to show Windows is broken, and YOU are the attacker making up this long filename to inject code into your own process, then a buffer overflow isn't a vuln.

Still as I mentioned on Raymond's original post, this doesn't quite work as Windows has things like Software Restriction Policy (and AppLocker). With that in mind, it is a vuln in the app if an app lets you inject code since you couldn't do so otherwise.
I think the point was less about a rootkit and more about maintainability. That said, a secondary repo hosted on SSL with trusted keys is a lot more secure than piping a curl'd script into bash. If you trust the application developer but not the infrastructure in-between anyway.
> This doesn't need to be a language feature, but this is possible on the JVM afaik (see Clojure).

You don't need Clojure; Hot Code Replacement was added in Java 1.4 (yes, that's 2002) and has been supported by application containers as well as IDEs since then.
What a colossal waste of resources.
How Shopify handles 300M uniques a month running Rails, Docker, and MySQL
I notice that the old-school Common Lispers tend to call their language "Lisp." I (a new-school one) always say CL or Common Lisp. I'm not sure why they do that. When I say "a lisp" or "lisp" I'm referring to the family of languages or some idealized lisp.
In that case the tech companies are hardly at fault for California law.

Push comes to shove they don't generally assert their theoretical rights too aggressively in my experience. However their lawyers don't want to abandon any rights that they have without examining them on a case by case basis. The ones that I have see balance that out pretty well and do have a release process where they approve personal projects.

If that balance doesn't appeal to you, then you can solve the problem by working for a smaller company where it is less of an issue.
You say you have to rely on humans and heuristics to determine which CL to revert. Couldn't you automatically re-run just the failing tests on the batch?

More importantly, you seem to be running all the tests, as often as you can. A commit changing a text label shouldn't require running all the tests, that just doesn't scale. Have you consider splitting Chromium into different projects, where commits for one project would result in the tests of that project, and only that project?
Go and Artificial Intelligence Tech Talk
Go and Artificial Intelligence Tech Talk by Tim Kington --- http://blog.fogcreek.com/go-and-artificial-intelligence-tech-talk/
I wonder though, there /have/ to be merge conflicts? I suppose you continually rebase on the HEAD of master to keep up to date? So instead of taking care of conflicts at the end of a 'dev cycle' you take care of it in the middle.

Did I understand that correctly?
Emacs Artist Mode
This is great advice. I sympathize with some of the concerns in the original post, which is a big part of why I haven't been a full-time employee in 16 years. From reading the comments of others, it sounds like going back to being an FTE would be quite a shock.
Woah. It's crazy how similar the air frame design is to all of the 5th gen stealth fighters being produced.
Here are the options one has when trying to make a phone:

1) Write your own OS from scratch
2) Borrow an existing OS (e.g. Linux) and build all of rest of the layers and services (e.g. Tizen)
3) Borrow an existing mobile OS (e.g. Android), and build all of the rest of the layers and services (FireOS, etc)
4) Borrow an existing mobile OS (e.g. Google Android), and all the layers and services

What vendors seem to be saying is #1, #2, and #3 are "too hard" and that consumers are demanding Google's Apps and Services. What these manufacturers want to do is, design some commodity hardware, put on the stuff consumers are demanding (Google's services), but then load them up with other stuff (which many consumers would call bloatware or junk).

But how easy should one expect it to be to ship a phone? Seriously, 10 or 20 years ago, you not only had to make a lot of custom hardware design, but you had to have a lot of inhouse embedded software engineering. These days, most of this stuff is available off the shelf, and Chinese manufacturers can slap together a new phone and drop Android in it extremely quickly, all at low cost.

If there was no Android, and just two proprietary platforms (iOS + Windows, or iOS + Symbian), their situation would be even worse.

Android's brand already has bad branding from fragmentation and security issues. Paradox of choice tends to drive conformity and commodification, so I'm not sure the situation would be much better otherwise.

If you want to launch consumer phone hardware and get lots of customers, IMHO, you should expect it to be hard and differentiating and have to put in enormous software work. I honestly don't think Android manufacturers are going to standout on small software tweaks and packaging of apps.

If you're an Android manufacturer and you think the key to standing out in innovation, I don't think it's going to come from skinning Android and replacing one of apps on the homescreen. Just IMHO, but this seems more like companies wanting to take shortcuts without putting in the hardwork that Apple or Google have made to convince users of the value of a custom platform.
What's the point of this? You'd only ever use it if you were about to have it seized, and doing so would be destruction of evidence.
The MITM is not "getting around HTTPS". It's exploiting vulnerabilities in web apps. Hence the paper's name of "Cookies Lack Integrity: Real-World Implications" instead of the nonsense "bypass HTTPS" title used here.
I take a neutral stance on this: the JVM isn't as amenable to the exact kind of concurrency that Erlang provides (green-threads with local GC backed by immutable data), but that isn't a fair assessment of concurrency.

Erlang (et. al. green thread models) has a method of concurrency that works well for situations you're using Erlang for. It's not the most efficient or most technically advanced mechanism for handling concurrency.

That being said-

> Without virtual machine support, doing concurrency is really just faking it

This is patently false, because it implies that:
- A VM is necessary for "real" concurrency
- (by deduction) Anything not utilizing an erlang-identical model is "faking it."

> will result in significant bugs later on that are essentially impossible to debug

I'm going to need to see an anecdote or citation for this.

Personally-speaking, I have a much easier time (quickly) understanding the execution of event-loop-backed cooperative multitasking than high-level, arbitrarily-preempted threads.

Also - I cannot see any reason why Quasar for the JVM would be any easier or harder to debug (from a theoretical, not tooling or practical standpoint) than Erlang actors.

The nuances differentiating the two models aren't great enough to merit bugs that you might see in one place or the other. Unbound, CPU-heavy tasks will cause problems for both systems.
KMPlayer+Review+|+Software+Download+-+FileBistro.com
I've read most of the comments so far but I've yet to come across an instance where someone mentioned an actual security compromise they knew of because of this.
>>You're forced to declare them before they have a sensible value to use.

As I said I like it because I like seeing what will be operated on when I start reading a block. I don't need to initialize them just yet.

>>You're exposing your code to unnecessary bugs where you user the variable prematurely.

The compiler warns when you use uninitialized variable. Just don't initialize them to random things, leave them uninitialized.

>>Variables tend to be declared further from their use, making it harder to find them and see their types.

I mean, I can see how that could be a problem but I don't have blocks bigger than one screen so I can alway see them anyway. I like short functions/blocks. It's also way easier to visualize what is happening if I allocate memory in my brain for the variables so to speak.

>>The stack size argument is wrong, because variables aren't necessarily on the stack, and non variable allocations may be put on the stack (i.e it's neither necessary nor sufficient to predict stack use).

It might be technically wrong but the real problems are arrays as they are the only thing which could blow out the stack (especially in recursive functions) so yeah, I don't see it as a problem although I imagine it could be for some.

>>You're discouraged from creating intermediate variables that aid readability.

I am not discouraged. Again, maybe it sounds super strange to you but I am actually discouraged if I had to put them in the middle of the code logic as I find it ugly and I need to readjust my picture of what is going on once I encounter some new variable I didn't know is going to be there when glancing at the block.

>>You're discouraged from declaring your variables const, losing extra safety.

I think const is as good as useless in C when it comes to declaring variables. I don't think it gives any extra safety it's just more typing and additional pain.

>>All in all, it's a terrible way to code.

I don't know. I think you lost the perspective. One way or the other it won't be a big difference and a lot of good code is written in the old/traditional style. You may think it's worse but it is not terrible.
If you have money coming in and out, does it really make a difference?

Some people make a lot of assumptions, but I bet none of those people ever tried Bitcoin.
That's a good application for Intamin's Mountain People Mover.[1] Intamin builds both roller coasters and monorails, and for a ski resort, they combined the technologies. It's a personal rapid transit system which runs on roller coaster track. Steep hills are not a problem. Nor is snow.

[1] http://www.intaminworldwide.com/transportation/MountainPeopl...
When you discover a sale or coupon through CouponMate, and checkout on a affiliated merchant site after that, we earn a commission from the merchant.

Does this browser plugin interfere with and/or override tracking cookies from other cashback/points portals or is it additive? If it replaces, is there any way to disable or choose which one I'd like to use?
Ok, we changed to that URL from https://www.periscope.tv/w/1MYxNbWRavLxw.
We are talking about top of the block. When you are creating a parallel section you have a new block/scope there so that argument doesn't apply. Both styles are the same when it comes to scope of the variables.
In the long (very long) run it could solve this problem too - if all cars were fully automated and very safe, they could travel much faster even inside cities, thus augmenting the bandwidth of roads.
The Road to Damascus
The one (additional) problem I see with piping the script directly to bash instead of an intermediate file is that it leaves no trace of what was actually run.

Using an intermadiate file like 'curl ... > temp.sh' and then 'bash temp.sh' actually leaves a file which can be looked at before (and if not removed by malicious code) after the installation.

As others pointed out we are giving control away of our computers if we install software. We are giving more control away if we don't use a signed central repository system we (and others) can check openly. We are giving more control away when we can't check that repository. We are giving more control away when we download non-signed binary installers from some a specific site. We are giving more control away when we download installers from some site somewhere on the internet. We are giving more control away when the installer downloads the files itself and leaves no trace. We are giving more control away when the installer auto-updates software from some source somewhere we don't even know what happens anymore.

In that light, the difference between using a temporary file and directly piping is little in security and little in convenience. Downloading the most recent release would be a bit better but a bit more inconvenient. Having it distributed via a signed repository would be a bit better but probably slower and cause more overhead on the developers side.

These differences are not very big and YOU can fix them by doing the additional work. The heated discussion about a tiny detail is a typical symptom of our culture. If the developers of sandstorm promote the convenient way but still provide the more secure way, good for them, so be it, let's move on to things that actually matter.

After all don't forget the fact that sandstorm is bringing the cloud back to earth into your basement. It is designed to conveniently run cloud applications locally so that you don't have to upload your data into some cloud but keep control of it locally.
You can export the scripts from an rpm without installing it.
Ever heard of Lisp 1.5, UCI Lisp, MacLisp, ISLisp, New Implementation of Lisp, Lisp Machine Lisp, Standard Lisp ,Franz Lisp, Emacs Lisp, ISLisp, Autolisp, Visual Lisp, and many many other Lisp dialects?

Notice something?

These all have Lisp in their name. They all share a core language.

None of those is Common Lisp, but Common Lisp is directly related to them, since it also shares the same core language.

Common Lisp can easily run Lisp code from 50 years ago.

Newlisp can't.
Didn't Aaron Patzer explain this, back when he concluded that Swift PRT wouldn't work?

https://web.archive.org/web/20140723180502/http://swiftprt.c...
Yes, I agree that not all learning algorithms are perfect.

Is it your belief that we can cook up better algos/data collection methods/etc and all the people complaining about "bias" in algorithms will be satisfied? I don't believe that is the case, given that no one is actually complaining that the algorithms are getting the (factually) wrong answer.
This is not a feature, as very few people expect it to work this way. The mental model people have is that they give out their card number only, not access to the underlying account. If I lose a card and get a new one, I understand it's my responsibility to update that number at relevant recurring charge accounts. Is that annoying? Sure. But if you aren't doing that, it is your responsibility to tell me in giant bold red letters that I am granting you access to the underlying account, and allow me to agree to that, and then confirm again that I really want to agree to that.
No, no, I was just plugging that in because in reading the other comments it was clear that lots of other people had NOT read the article, and were missing the point, and I wanted to call attention to your summary.
Service sunsets aren’t the least bit pretty
I need more details that I can't find in their FAQ[1] and it's not all open source yet[2]. My main question is about metadata which you cannot really protect that well w/ how SMTP works. The second question would be how different this is from PGP/Mailvelope[3] and where the keys are stored for a user (i.e. the "trusting" you are talking about).

1 - https://www.virtru.com/faq/
2 - https://www.virtru.com/blog/virtrus-open-source-strategy/
3 - https://www.mailvelope.com/
Sorry, I was unclear. I was expressing my view, and not trying to explain any kind of legal position. What I was saying was that I cannot see how a company can justify owning everything I do outside of my work hours. Whether or not that is in my contract is a different matter. I would urge any potential employee to negotiate any such bad contract if they can.

If my job involved taking clients out to dinner or answering pages in the middle of the night regularly, I would damn well want to be paid for it. Not per-call, but the additional workload would have to be reflected in my salary.

Put it this way: If you are a programmer who never has to do any out-of-hours support, and then suddenly your boss says that you need to be on call 24x7, you'd be a fool not to ask for more pay.
When Stroustrup created C++ or Hejlsberg created C#, did C progammers spend decades whining about their choice of names and alienating newcomers?
Yes indeed. From a slightly different perspective, assuming every good dev tries to be as efficient as they can be, even assuming they are, but with varying degrees of success due to various factors, a big company can hire lots of good people and only needs to get lucky and hit the mark occasionally. A small company on the other hand has to get lucky pretty much every single time.
So which governments get access to the 3rd keys?
Kickstarter nixes its 'flexible' vacation policy
Virtru escrows the keys, at least that's how I interpret this diagram: https://www.virtru.com/technology/
New York City MTA (bus+subway) does ~8 million rides a day. I don't see this replacing that in any practical way.
معلم تركيب رخام الكويت هاتف 24731328
KAIST's HUBO drops in for a visit on Day 4 of euRathlon
We actually are working on systems which re-run the failing tests on all CLs within a failing batch. Unfortunately, we haven't been able to do this previously due to resource constraints. In particular, if a batch had 10 commits in it, you can either run 10 additional compiles and tests (didn't have the resources), or you can binary-search/bisect to find the failure (takes too long). It is often faster to use a heuristic to say "Test_Foo failed, and Foo_Src was modified in change X, so revert change X". We don't like relying on heuristics, but until recently it was our only choice.

We actually don't run all the tests all the time. We have a good dependency system (called Gyp/GN, similar to Bazel) which knows which tests rely on which source files. When the infrastructure compiles a new change, it only runs the tests which depend on source files touched by that change.
I admit that I have a fondness for learning esoteric languages. That said I've actually gone far enough down the urbit rabbit hole to write a set of tutorials[0].

urbit has a high startup cost and is hampered by a lack of documentation as well as a desire to reinvent terminology as well as a fast changing API to write too. All of which means that it's more suitable for the curious and hobbyists right now.

I'm withholding judgement on whether it will manage to succeed despite these.

[0]: http://hidduc-posmeg.urbit.org/home/pub/hoon-intro/
I suppose. Though have you considered the fact that if someone has non-root local access to your machine, they are just one local privilege escalation away form becoming root? And these things come out fairly frequently that you can pretty much count on one being found soon. In other words IMO you should either trust or not trust a piece of code to run on your machine. The distinction between root and non-root user running the code is more for maintainability and sanity and less for actual security.
Hmm, interesting. It works in a simple test case, but fails to compile my codebase and throws an error

./inc/bla.h:163:9: error: unexpected '#pragma omp ...' in program [-Werror,-Wsource-uses-openmp]
#pragma omp parallel for num_threads(Threading::num), schedule(dynamic, 1)

Unfortunately I wasn’t able to build a minimally failing example so far, I will have to investigate this further. Thanks for the heads-up in any case!

Edit: Turns out everything fails if -Weverything is supplied. I didn’t offer a runtime library (nor did the compiler define the _OPENMP macro even when having -fopenmp on the command line, otherwise it would have complained about a missing <omp.h>…). If -Weverything is not there, the thing compiles but only runs with one thread.
Can your app avoid Google's naughty list? Test it against real-world conditions
Evading Apple's policies isn't a security thing, though. What keeps the system secure from malicious activity by your app is the sandbox that your app is executed in. Putting in exploits that you then use yourself is just a weird way of obfuscating your code to bypassing non-security restrictions, and it's one that involves way more effort than is necessary. Much easier and just as effective to embed a small interpreter and make a HTTP request back to your server on launch to see if it has any code for you to run.
Stereotypical Silicon Valley startups are built for fast, reckless growth which cannot and will not happen with a government contract.

FWIW, there are plenty of us here who aren't in Silicon Valley and who aren't interested in building a "stereotypical silicon valley startup that is built for fast, reckless growth".

I don't disagree with your point, just wanted to point out that the audience here is broader than just SV people.
I took our kids to find one of these ("ecoducts" in the Netherlands) about a half hour drive from where we live. It was fantastic: no sign of humans anywhere except the speeding traffic under us on the motorway; just lots of animal footprints, and a single surveillance camera that I imagine is used to check out the furry users of the bridge rather than for any "security" related tasks.

The kids loved it :) They found it pretty spooky though.

It's very weird standing on what feels like a big hill with grass, sand and trees, knowing the motorway is rushing by under your feet.
My point is, it's amazing that it's better at decoding phonetic sequences (which are presumably garbled by passing through a human being (me) who doesn't understand them), than a human being who has evolved to use language and has over 30 years of fluent experience.
The tools designers are using today
Good call - I am not as familiar with JVM-hosted languages, though I knew Clojure was capable of hot code replacement (as any lisp should be!)

This is definitely not a new idea.
What makes you say that? In the case of the I-90 project in the linked video, they addressed issues of risk and cost, as well as proof of use by animals, in the planning stage.
The difference is that, in our flow, the merge conflicts are on the scale of a a single developer making a single self-contained commit. In a flow with feature branches, the merge conflicts are on a scale of the entire branch conflicting with any other changes made on master.

But yes we also provide tools (https://commondatastorage.googleapis.com/chrome-infra-docs/f...) to make things like rebasing (see git rebase-update) your local branches on top of master easier.
awesome, but is it over after the connection is totally killed? doesn't go anywhere from there, would really like to see where this goes next, cheers
Google voice search also has anaphora, or backreferences to previous searches. For example voice search for "Who was the first president of the United States?" then after you get the result do another voice search for "Who was his vice president?" and Google will infer you are still talking about George Washington.

One step closer to conversational interfaces!
Yes and as OP was pointing out, just because you regard them as powerless doesn't mean they are powerless. You can't simply make rules for yourself outside of society because you wish it so. You may, in your mind, disagree. But in reality you will be subject to the legal rules of society.
That is not a thing a cookie can do, so while it may be sad, there's not much to be done about it.
It would probably be a huge pain to migrate all 18,000 classes, tests, tools, etc., over to a React Native app. Also JS has less fine grained tooling for performance profiling (try stepping through JS bytecode for performance analysis, it's a PITA). One day it might get there, but not today. If it works, why change it?