Hacker News new | comments | show | ask | jobs | submit login

Don't buy Hyundai.

So at the point where you have a good-faith question about whether someone is violating the Code and harming the project, you must assume good intentions? Do you expect a sexist Bob to say out loud, in a project space, "Yup, I'm judging contributions on things other than technical merit" (especially when Bob can just tweet "Broads can't code lol" and it's defined as a thing you can't pay attention to in the project)?

Why not just replace the code with "No one can possibly behave poorly for the project, just believe everyone" and be done with it? Seems equally effective.


This video is legendary. It's like sitting in on a university course on the technical details of the physics and programming in Mario 64.

Chrome / Mac. It worked okay on my other computer, also Chrome / Mac.

I feel that the focus on infrastructure _is_ the content. It may be over the top (dithering is especially BS), but without battery indicator how many people would discover that the server runs on sustainable solar power?

Confluence is an example of a piece of software that wouldn't run correctly at all under OpenJDK.

Even today on the Atlasian docs, they provide a Docker image of Confluence to evaluate, but if you buy a production license, you are required to build an OracleJRE Docker container (they provide instructions) for production.

It's been years and they still can't support OpenJDK ... it makes me wonder what weird proprietary crazy reflection shit they're doing in there.


Like many other things--such as many conference presentations--a lot of podcasts would benefit from being trimmed for an hour or more to 20-30 minutes. If you listen to most professionally-produced hour-length segments on radio or podcast, even those are usually broken into multiple segments in some shape or form. An hour-long straight conversation is way too long IMO.

Yeah, totally! The gitter is where most conversations about this take place: https://gitter.im/nebulet/nebulet

What I really want (and I will annoy you by talking about J instead of Dyalog) is resources for intermediate users, because there is a significant amount of literature for beginners and experts but I agree with Hillel that the road between the two levels seems to be unmitigated struggle. The Finn idiom library may be useful for APL users but even looking at it, I don't see what the purpose of it is, unless perhaps you're just supposed to read the expressions and learn novelties about how to use the built-ins.

The approach I've taken, which I think is common and slow and easy to "fall off the bandwagon", is to write my solutions to my problems on my blog or email the J mailing list and see if the experts can improve on my code. They always can, if they care enough to show me, and they usually do. But as I mentioned in my other comment, I think one of the wonders of APL/J/etc. is that it seems to share even less with conventional programming languages than it seems to at first because the way APL programmers decompose problems is radically different. I often find myself trolling through the dictionary looking for things that I wouldn't need if I didn't break the program down into as small pieces. Choosing the right verb is partly tactical, but the whole strategy for attacking problems is so unconventional you are often looking from the wrong vantage point.

I don't know if there is a royal road to APL that addresses this, but I share Hillel's desire for one. I suspect there isn't, and the only way to really get better is: read lots of code, write lots of code, get feedback on your code, repeat.


This is something I struggle with every single day for the last year. I value how much I get out of work in terms of learning and improvement and have had a pretty ok last couple of stints with a lot of things happening outside of my control.

I wish this could be easier.


"If you’re in a room where a child has just fallen asleep, and someone else walks in..." considering the other person as Alexa bothers me. I appreciate the tech but the fact that Alexa/Amazon corporate is participating, even passively, in interactions with my children and myself causes me pause.

The dithering is nice for some images but it takes some details on graphs etc..

The example image given can be re-compressed using techniques like structural similarity (SSIM)[1] or Multi-scale structural similarity (2008 Paper)[2]. Using jpeg-archive[3] I resized the example image in the blog[4] with decent results:

  /tmp  ls -1sh *.jpg *.png | sort -nr
  740K 6a00e0099229e88833022ad3b23825200b-750wi.png
  100K 6a00e0099229e88833022ad3b23825200b-750wi.jpg
   64K small-fry.jpg
   56K mpe.jpg
   24K ms-ssim.jpg
[1] https://en.wikipedia.org/wiki/Structural_similarity

[2] http://foulard.ece.cornell.edu/publications/dmr_hvei2008_pap...

[3] https://github.com/danielgtaylor/jpeg-archive

[4] http://krisdedecker.typepad.com/.a/6a00e0099229e88833022ad3b...


Yes, but this is referring to a specific TAS (the current fastest known one), not a possible TAS.

http://tasvideos.org/Game/nes-super-mario-bros.html


I couldn't agree more. I was a maintenance programmer/developer for 30 years and saw too much of this. It disgusted me to the point where I just rewrote entire systems during slow periods (unauthorized and on the sly). The Amiga OS had full multi-tasking with robust, inter-process messaging, and a full-featured windowed GUI that fit onto one 720K floppy so there is no valid reason that we need multi-gigs for the current version of Windows. I'm posting a link to your excellent article on Daniweb to encourage discussion.

Reverend Jim (on Daniweb)


I'd say it's car centric depending on where you live. I designed my life around being able to walk everywhere I need to or hop on the CTA to get places I cant walk. But I'm in a rare part of the city where I can walk to the red line or blue line in 5ish minutes. If you live elsewhere, or cant afford to uber from time to time, a car would be a big plus.

> Such interface will allow to effectively use persons with average IQ for problem solving, like calculators allows to do math easily for just anybody, but it will not generate geniuses.

Motorbikes don't generate world class sprinters either but they sure get you from A to B faster than walking.


yes, no not to the engine, yes, no and most but not all.

That's a common, traditional form for non-lining numerals (https://en.wikipedia.org/wiki/Text_figures)

Turns out, Al Gore doesn't like it, either: https://www.typotheque.com/blog/gores_choice


I would pay for a source of journalism that had any actual effort put in it and wasn't blatantly and hilariously wrong almost all of the time. Sadly news agencies don't fit that bill at all.

If you trust your ability to secure a publicly-accessible DNS server. Pretty attractive target.

Also, you can't usually specify DNS servers on cellular connections. The VPN setup would address that.


Just as a note, a project being open-source doesn't necessarily provide a 100% guarantee that it doesn't contain any (possibly obfuscated) malicious code. Our community likes to think that someone else would catch it, but enough people thinking that way can (and likely often does) lead to the bystander effect. So it's always good to be wary :)

As a related note - why do employers prefer younger devs? Because they haven't learnt this lesson yet.

uBO can block with pattern-matching URLs of network requests and additionally cosmetic filtering (hide DOM elements), while uMatrix works strictly with hostname of network requests and types of resources.

I really wish I could remember where I read this so I could give proper credit --

Somewhere I read a helpful way to rephrase "blockchain" that really helps cut to the heart of the issue when you're dealing with technical questions like this: The blockchain is just an ordered series of files, each of which contains a hash of the previous one in the series.

So, when you've got someone saying, "What if we use blockchain?", just mentally substitute the suggestion as, "What if we store the data as an ordered series of files, each of which contains a hash of the previous one in the series?" Any bits of the proposed system that aren't impacted by the decision to store the data as an ordered series of files, each of which contains a hash of the previous one in the series, also don't have anything to do with whether or not it needs to involve a blockchain.


> Point is: There is useful information even if certain steps can't be perfectly traced.

Yes (and no), but that's not what IBM is selling with their blockchain. They're selling trust, but only providing a digital trust solution while completely ignoring the physical and human side of trust.

> There is value in not having to connect to a central database all the time.

Problem here is IBM's blockchain is still a centrally maintained database. This literally provides any value. You still need to connect to a central database at some point.


Yup, that's a downside. The advantage is that it's much simpler and will also work when you're not on your home network.

The logical reasoning is full of gap and holes that I cannot bother to rebuttal, because I am afraid of wasting my time.

But I think Block chain can succeed. It matters less that it works, as long as the rich and powerful believe it can help then sustain their status.


The OpenJDK build is GPL and should find its way into official package repositories. Oracle may have stopped creating the rpms for that reason.

Most distros use the IceTea builds for OpenJDK. Hmm . IceTea3 is Java8. There's no Java9 IceTea4 build yet. I can't find any roadmap info on their site ...


I'd say that it is rather obvious that ray tracing is not a new thing, since it is simulates how light physically behaves.

I consider this 3d rendering as a spectrum: rasterization requires little computation but has little to do with physics. Ray tracing is what requires a lot of computation and has everything to do with physics. Somewhere in between are hybrid methods: rasterization with ray tracing components added to it, or ray tracing with approximations.

For instance, pure rasterization cannot do shadows. It is approximated by rendering the scene from the viewpoint of a light and test the rasterized scene for occlusions casting shadows. And the other way around: real time ray tracing cannot compute all indirect lighting paths, a subset is only considered at the cost of e.g. variance.


Looks awesome! Quick note about the landing page: the GIF captures in the "How it works" section are a bit vertically stretched, weirdly pixellated and really too quick to understand what's going on.
More

Applications are open for YC Winter 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: