usernam

At least here, the driver of the vehicle hitting anything (another car, especially a person) is /always/ responsible, because you're supposed to be attentive for unexpected events. And that's how it should be. Why do you think otherwise? If you don't see clearly in front of you because of scarce illumination, you should go slower.

Unless assisted driving is close to near perfection (that is, it becomes a true auto-pilot without the need of assistance), we're going to see much worse numbers of accidents on the streets for assisted-driving cars.

Assisted-driving requires the same, if not more attention, as it essentially becomes like supervising an inexperienced driver that is prone to make stupid mistakes in otherwise normal circumstances. If you ever had a kid, you should be pretty familiar with how stressful this is.

But thanks to the PR spin, the driver is led to think that he can keep less attention, until he pays none at all. Assisted driving is even more boring than regular driving, lowering the attention span.

What could possibly go wrong?

We're getting enough candidates, but many good ones are simply turned off at some point because the salary or position doesn't match the high expectations we implicitly set.

This, in turn, results in a process of exclusion during the process more than actual evaluation (which then begs the question: why put such high requirements?).

I'm pretty sure we're discarding individuals which are just too afraid or see themselves too conservatively. I'm not afraid to say that I ended up in my position by pure chance, and probably wouldn't pass the hiring method we currently use, despite being here for quite a long time.

I'm not really making any. This almost seems like a completely different way to present yourself which is taught to people.

I would say that indian CV are simply on another level, I have no clear idea why. We're posting positions online, and the openings are often automatically indexed by several job search engines. Maybe this is because indians are just more exposed to online hiring, working abroad and generally simply try to get an interview.

Let me reinstate that also this is not universal. We had very good candidates which didn't inflate the resume, thus my point that I really cannot look at the CV by itself. This is very detrimental for both.

I took "germans" as a stereotypical example here. Thinking back, most qualified applicants anywhere in EU are in a similar ballpark. I would say a small amount of inflation is common, but senior applicants generally match much more closely the qualifications they presented. I didn't have many applications from other eastern countries to say anything else.

I'm also not an HR guy. I just participate in the hiring process when the need arises.

The barrier is lower for applying, but as many other posters saying, there is simply just interest in quick ROI and zero willingness to think long term.

I recruited for several years for my companies too. First thing I noticed, there is huge variability in CV for each country. When I receive a CV from an indian person (from India), I don't know if I should expect 100% lies or what, even from qualified seniors. On the other end, I could put my hand on coal if the same CV was written by most germans. Which is bad, because the CV or cover letter become essentially useless as a metric.

To reduce the number of applications we introduced simple tests to submit along with the CV. It does wonders, but I personally hate it. As a senior dev, I keep asking: would I apply to my current application? I have to answer that no, I wouldn't. I have plenty of public projects to investigate my abilities if needed, and I do expect some minimal amount in investment from both parties when hiring.

We also raised the requirements from applicants ridiculously, essentially expecting them to work on core features from tomorrow. Again, completely unrealistic. And again, by our own wording, I would be afraid to apply. We are definitely selecting over-confident candidates (or desperate).

And it's sadly also true that the industry has no apprentice jobs anymore, although there is plenty of need. There are some career paths where I would jump ships despite my lack of expertise to follow my interests. Starting from zero doesn't stop me, but there are simply no opportunities: junior jobs are not really junior anymore. They are simply paid less.

Marginally related: is there something native (and for linux/unix) equivalent to shadertoy? When debugging a sharer it's quite handy, but the web interface is just too laggy for me.

I'm currently using my own simple test rig, but I'd like something more refined.

But is it? I don't actually think it's bad design. Having system images of a pre-loaded heap is pretty common in many systems and languages. How such systems are generated and loaded vary, but they always come with some tricky issues. This is especially common in lisp-like systems.

The whole lisp implementation is emacs is a bit crummy, but I don't get the excessive criticism against unexec. I consider lexical binding a much a much bigger oversight.

I would have several actual uses for VR, and from the top of my head I'd kill to have proper depth perception and enhanced controls while modeling the solids I have to make.

The headsets make today would meet my requirements perfectly. The price is not an issue. As a coder, I wouldn't have any problems with just a library exposing the display and sensors.

However the VR market is just full of BS and lock-in. I'm not moving an inch on any of these closed platforms.

I'm not sure I've seen any "user interface innovation" done with HTML.

Pick a book on GUI interfaces of the 80ies (for example: Computers Graphics by Foley & al), and see that pretty much all UI paradigms themselves were pretty much explored back then. The concept of the "hypercard" was already there.

HTML just improved on the presentation of it, often worsening everything else. Somehow web apps lowered the expectations of what a computer /should/ do so much that usability itself became an afterthought.

Some of the best designed apps on the web mostly ditch the DOM and layout everything in JS. Hardly "innovative".

You're trying to conflate document design with UI design. By the writing of the author, he is clearly doing just fancy documents. He didn't even touch the problematic issues you normally face in web development.

You can do pretty neat things with trivial html/css these days, where you needed quite a bit of JS just 5 years ago.

Platform GUI toolkits are designed for controlling an interactive program from the start, a very different usage scenario. They were never designed to be documents to be read from top to bottom. Traditionally, GUI toolkit almost never included fancy text layout boxes just for text display. To give you an example, a simple text label to be used next to a button almost universally could be of a single font with the same style throughout.

I wouldn't even consider this a limitation, because on toolkits with advanced theming (GTK/QT), this allowed for a very consistent layout across all programs, which is clearly a much better user experience for the user as opposed to styled individual applications. Somehow, this crucial bit of /actual/ usability /design/ was lost.

The irony? Current GUI platform toolkits are actually copying the document model of web pages instead, so that your layout skill set can be more easily transferred across systems. So you can finally style your button's label to your hearth's content. XUL is probably the first example of this.

As if "layout" was the major issue in desktop user interfaces (HINT: it's not).

Now we have GUI toolkits which are basically web views that maybe call some native code. In my opinion: a huge failure in engineering and user experience.

My take from the experience was that if you have an active social life outside of your colleagues and work is "just work" for you, then a full-time remote job is probably fine. Saves you the commute too.

I do have an active social life, but I expect my work to be something more than "just work". I enjoy what I do, and working at a distance detracts from the experience.

I worked remotely for more than two years because I had to move to another place. I loved the company and they were quite happy as well, so they let me work remotely full time without problems. I absolutely loved it for the first six months, then I quit my job after the second year despite being a "dream scenario" for many.

I generally work alone when I want to think, but I loved the interaction with excellent colleagues and sitting at home with skype wasn't exactly the same.

I would still work remotely for 2-3 days a week, because it's so much more productive for certain tasks, but no more. I do not consider full-time remote jobs.

This has not been my experience, not at least in research or IT/research sector. More hours do not translate in more results _or_ more focus.

I've seen also an inverse relationship in quality of work and work streaks also in other fields, for example a direct experience for me was automated textile production. More hours in this case has a direct relationship with more product, but results in more stupid mistakes and more importantly I've seen less overall feedback from the production line, where employee are just more eager to say "fuck it" and simply do the work as opposed to try to help in improving the production process. There is a fine line between using your employees as a resource or a brutal work-force.

This was an eye opener for me. There is definitely a balance in every part of the production line, and less work is generally good for everyone.

Interestingly, it seems to lose 1/3 of the inputs I'm trying to send...

Whoa there: fixed top banner with an actual banner at the top, covering a whopping 20% of my screen height and 80% of width. Didn't see something like this in a long time.

I'm never going to interact through that as a developer on daily basis. Not even considering the poor UI for just every feature in SF.

The only thing SF has for it, currently, is a mailing list for each project. GitHub and GitLab should have this. Interaction and discussion though "issues" is horrible.

As a developer, I'm not so sure about that: I don't use any web and non-native program by choice. In fact, I'm even stricter than that, I can tell you at a distance if a program was written using QML instead of QtWidgets (due to lag and poor behavior) and avoid the first just as I avoid non-native apps.

In fact, unless I'm restricted to a single program I don't have any alternatives to, I'll generally even select programs written in a language I understand and/or prefer.

I have several colleagues that use slightly different metrics, but still pay very close attention to performance and details of the tools they use. Especially if that's something they use for hours over the course of a day.

I read both, and I can confirm that meltdown is not fixed by the microcode update alone. But I'm confused by intel claiming a fix for all three variants of exploits: I would have realistically expected a proper fix for meltdown, but it seems that intel can't really fix it in microcode.

Commenting on the upstream bug tracker would do so much more than lazily clicking upvote.

Can somebody shed some light in what exactly the released Intel Microcode update does aside from exposing some chicken bits? This is only marginally addressed in the "Controlling the Performance Impact" page linked above.

For example, does the update fix Meltdown in any meaningful way? If so, does it mean that "pti" should be manually disabled on a patched intel cpu to avoid _additional_ overhead?

It seems that the kernel changes being pushed do not account for the current published microcode updates.

Reducing the resolution coming from system timing sources is not going to stop attacks which have potentially infinite execution timelines.

Limiting JS execution resources, and in particular CPU cycles, will actually stop instead a whole swath of timing and resource-dependent attacks.

Please put your thought and chime into this thread:

https://bugzilla.mozilla.org/show_bug.cgi?id=1414675

Allowing infinite resources for remote programs is something we don't even do for local programs. Giving a ceiling to the JS runtime is a sound reasoning.

Please comment on the bug tracker!

It's a classic problem with markdown: it's a minimal markup language, which is ok for comments and super simple documents, but requires extensions for pretty much anything else.

This is why every week you see a new markdown implementation which is just ever-so-slightly different than the other, with every service and tool implementing it's own. I dread markdown, because I know there will be extensions. And the extension syntax doesn't look nice/simple. Syntactically, asciidoc or rst is much more thought-of than any markdown-like syntax I've seen.

This is also the main reason I really discourage markdown for anything but a comment system. Just start with something more complete if you plan on documentation.

I was strongly against md on the documentation for julia for exactly these reasons. Not even one year later, md in julia is already contains extensions which are oh-just-very-similar-to-but-not-quite the others.

Since I've discovered "nickle"[1] (by pure chance), I've been aliasing bc=nickle on every system I had access to.

nickle has normal algebraic notation with arbitrary precision, configurable base input/output for every expression (very reminiscent of calc), math functions and C operators work out of the box. It has variables, as well as a simple c-like language for additional extensions.

If RPN is not for you, "nickle" is a perfect "bc" replacement which works as you would expect.

[1] https://nickle.org/manual.html

Exactly like Chrome. I do not argue about the good intention behind.

I'm not talking about Pocket.

I'm talking about A/B testing internal features exactly like Chrome, such as ip v4/v6 path preference, pipelining support, TLS faststart (and so on) according to a random cohort selection.

Firefox is not immune to this behavior. Please look up the preference "experiments.enabled" before recommending blindly.

In fact, Firefox has increased in the amount of unwarranted telemetry and "experiments" a lot in the last years, a direction I'm really not happy with.

The main difference is that Firefox still gives you pretty liberal access to most internal settings, while Chromium is abysmal, if not ridiculous.

There is plenty of work that can be done incrementally though. Contributing as a designer into an OSS project is no different in commitment than another programmer/translator/contributor would.

There's always a cost to contributing. The cost gets bigger as the project gets bigger. This is totally unsurprising.

This is why people contribute more to software they use. You don't generally jump ships and help random projects for the sake of it.

Not answering the concert regarding CT (I concur).

But the obvious answer for truly secure connections is your own CA root or a self-signed cert you manually install/enforce.

You don't want to pass through another CA if your service is private. You actually don't need to. In fact, you'd want to manually enforce a single root or distrust system certificates entirely when doing so to avoid the problem you describe.

Most decently-written software that supports SSL/TLS allows you do that.

The CA system is for services that you intend to make public.

Actually, modern (and not so modern) physics engines as used in games generally use a fixed time delta for each step, and just iterate faster/slower to keep the simulation in sync[1]. This is done for many reasons, but predominantly numerical stability.

[1] not the full story