Hacker News new | past | comments | ask | show | jobs | submit | more daxterspeed's comments login

Everything only searching file names might seem like a dealbreaker to some people but it actually provides a great incentive to give your files useful descriptive names.

I got Everything in a hotkey so it also doubles as an application launcher. It really is quite elegant.


These tests could be on a website of their own. I'd love to see how the results change with time and how competing implementations compare in terms of behavior (not necessarily performance), V8 especially has changed a lot but it wouldn't surprise me if it still ran into issues.


It seems to me like VR could get some great usage of vector assets. Having icons and especially text render perfectly regardless of how close you get seems ideal.


Yes! In fact, games use another method that could also be very beneficial in VR: signed distance-field rendering. As far as I know it's mainly used for text, but there is nothing specific stopping it from working with other kinds of images.

Essentially you get your vector data, and map it into a texture of distance from the boundary, with positive being outside the boundary, and negative inside. Then you apply a shader to that resulting texture to make it presentable for the user. This means crisp contours/outlines at all but the most extreme proximity, and easy implementation of other common vector effects (such as bevels, shadows, etc).


I'm not a huge fan of template e-mails, if you're just gonna do an automatic response then make that obvious from the start.

However I do see how these can be useful as a reference point, I especially like the templates/examples that have a little story behind them. Saying no "like a pro" isn't about the exact phrasing, but knowing that you can and often should say no.


Template emails are the worst yeah.


It's rather disappointing that websites can't request linear ("correct") alpha compositing in any way. I suppose it's a bit of fingerprinting, but browsers can already be fingerprinted by gamut support[0].

[0]: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/colo...


Valid or not several emoji domains have existed since 2001 https://en.wikipedia.org/wiki/Emoji_domain


As with so many things domain name related, what is or is not valid varies by and is determined by registrar. The biggest registrars (.com, .net, .org as three examples) generally have a lot of restrictions on IDNs, whereas many countries can afford to allow just about the full gamut of Unicode if they wish.


There's two arguments I've heard against removing the User-Agent field:

"It helps us understand browser share" and "UA sniffing is faster than feature testing".

I believe both of these could be remedied quite easily with some minor work. Websites shouldn't have access to browser version, cpu architecture, model name etc by default. Websites with legitimate needs for this information can request access from the user and the user would be in charge of determining whether the website has earned the right to this information (useful for eg. sites that want to report "last login at [date] from [browser] on [platform]").

In terms of UA sniffing being faster than feature detection old browsers will continue to send their outdated User-Agent strings. Websites will simply have to opt to use feature detection in actively developed browsers.

In terms of the server determining whether it should serve a "lite" version of the site, there's potential in headers like "Save-Data: on". There's also research into headers that would send incredibly coarse information about the devices capabilities (eg memory available rounded down to nearest 1024^n bytes).


> Websites with legitimate needs for this information can request access from the user and the user would be in charge of determining whether the website has earned the right to this information

That seems much like what the author is proposing: "User agents can make intelligent decisions about what to reveal in each of these attributes. Top-level sites a user visits frequently (or installs!) might get more granular data than cross-origin, nested sites, for example. We could conceivably even inject a permission prompt between the site's request and the Promise's resolution, if we decided that was a reasonable approach."


> potential in headers like "Save-Data: on"

Yes, headers, if added, should be about the capabilities of the browser, not the browser vendor, the underlying OS or hardware.


The problem with expressing capabilities is they will never be binary in the real world, and the feature set is growing constantly.

Often with emerging functionality, one vendor will do an experiment, other vendors will refine and it will go through the standards process. If Chromium first introduces `Whargarbl: On` and WebKit implements it differently, the header may become something like `Whargarbl: -webkit-frobnicate`. Dozens of headers like that may be sent.

This is almost certainly better suited to feature testing in the runtime.


No doubt, feature detection is much better. There are a few things that needs to be on the header-level, like compression standards and encoding, but the less data is attached to a request by default, the better.


Is there a simple command you can use to read the contents of the script (pipe) before it's sent to sh? Something like:

    curl ... | less-and-maybe-cancel | sh


Yeah, "vipe" from moreutils (which is a package on most platforms) does this. It inserts $EDITOR (usually vim) into the command pipe, and allows you to review and/or edit the text before passing it on to the next thing in the pipeline. Great little command line utility, for all sorts of things.

If you want to cancel, just erase the file. Or `:cq` in vim probably works as well.


You can pipe the output of cURL to Vim like this:

  curl ... | vim -
Then, you can review the script, maybe tweak it a little, and you can send it to sh's stdin by running

  :w !sh
Or you can just quit Vim (:q! or ZQ) and nothing happens.


The Maybe command sounds similair.

https://github.com/p-e-w/maybe


Semantic HTML sometimes creates layers of nesting that make it impossible to achieve certain css effects without either breaking the semantic markup or adding a lot of "pointless" divs.

In an ideal world HTML would be exclusively semantic content (eg, no div elements) and CSS would be exclusively styling (eg, no contents: property). display: contents; does allow us to get a little closer to that ideal.


I'd love to see PC devkits for this device. Something as simple as a USB 3 device you plug in and place under your monitor. Perhaps it will make its first "PC" appearance in a Google Chromebook?

I can see a lot of eccentric users figuring out interesting ways of integrate many of these gestures into their workflow. Perhaps for navigating in 3d space or switching between workspaces?

[edit] There used to be a developers page which showcased that devkits exists. http://web.archive.org/web/20181110202503/http://atap.google... Showcase video https://www.youtube.com/watch?v=H41A_IWZwZI


It will just join the graveyard of gimmicky vr/ar motion controllers.

Leap motion, Kinect, etc. Those can track precise skeletal gestures too.

I think the differentiation here is low power always on and attached to the phone with high field of view.


The Kinect caused a huge wave of innovation. It was a convenient and low-cost source of RGBD data, and many robotics labs got a few when it was released.


Could you expand on the result of said innovation? Where would I see Kinect driven innovation in everyday life?


Much of that technology was improved and miniaturized, and incorporated into the Apple Face ID bar at the top of the iPhone X.


Personally I feel FaceID is a step backwards from fingerprint readers. It doesn't work as often for me (facial hair, hat, lighting, hoodie, and sometimes it's just finnicky) and there are privacy concerns. The fingerprint reader isn't perfect, but for me it was better. I can touch it while pulling the phone out of my pocket and it's unlocked when I open it.

I'm frustrated with Google's choice to copy Apple and remove this feature from the Pixel 4. It's literally the only reason I'm not buying one.


What privacy concerns are there?


I guess it depends on whether or not you consider a 3D scan of your face personal data. As face-tracking becomes more prevalent, I'd say this is the worst thing you could voluntarily give away. Your face can be scanned just walking through a crowd in public, a fingerprint is only usable when you physically touch something (and the digital version is always prompted so you can't be identified in a crowd unexpectedly like you can with a face).


I would agree facial recognition in a general sense has privacy implications — but in the case of Face ID I think the implementation is sufficiently secure.


I agree Apple is one of the few companies that takes security seriously. That said, it only takes one hack/leak to compromise your biometric data forever. You can't change it as easily as a password. And you're voluntarily giving it up...for what? A worse unlocking experience? If it weren't for the novelty factor I am confident most people would not use it - probably why the hardware is removing it as an option. Also it's no secret those companies want the extra data for training better models and this is a "free" way to get really high quality data.

As far as things to bemoan in tech this is pretty low on the totem pole. I'm just annoyed because I wanted to buy a new phone and can't find one that has what I want at any price.

EDIT: I saw this article seconds after finishing this comment, which seems ironic.

https://www.bbc.com/news/technology-50080586


I think you should read up a bit more on the technical implementation of Face ID. The data never leaves the phone and, even if an attacker had physical access to the phone, they could not get the information. Apple is getting no training data from it.

> If it weren't for the novelty factor I am confident most people would not use it

I think this is really incorrect. You really think everyone is using Touch ID and Face ID only because of the novelty factor, and not because it's significantly more convenient (and, at least in many cases, more secure)? That if it wasn't "fun", everyone would be completely okay going back to entering 6-digit passcodes?


> You really think everyone is using Touch ID and Face ID only because of the novelty factor, and not because it's significantly more convenient (and, at least in many cases, more secure)? That if it wasn't "fun", everyone would be completely okay going back to entering 6-digit passcodes?

I meant compared to using a fingerprint reader, but even then yes. I returned an iPhone because I can't unlock my phone in the dark enough that I just got sick of it. My partner complains of the same thing, and vows to buy a cheaper phone next time because of it.

> I think you should read up a bit more on the technical implementation of Face ID. The data never leaves the phone and, even if an attacker had physical access to the phone, they could not get the information. Apple is getting no training data from it.

Thank you for this, it's useful. It still doesn't assuage me that it's impenetrable though, just that it would be incredibly difficult to obtain.


Face ID works way better for me. I couldn't get the fingerprint reader to recognize my stupid sweaty fingers sometimes, but Face ID always works for me.

You can unlock your phone in the dark. It doesn't rely on visible light, as it shines its own infrared light on you. You were probably holding your phone too close to your face.


I know how the sensor array works - I've personally built structured light sensors for robots.

It doesn't work for me. I'm glad it works for you.


Apple bought PrimeSense (the company behind Kinect) for $360m.

https://en.wikipedia.org/wiki/PrimeSense


A lot of early 3d scanners were just repurposed Kinects: https://m.youtube.com/watch?v=KOUSSlKUJ-A


I know of MSc and PhD work to use the Kinect as a low-cost alignment system for radiotherapy patients.


I meant that they didn't catch on in the same way say webcams or wireless headphones caught on among consumers.

I have personally built stuff with KinectFusion before so I do know how powerful it is.


Leap killed itself by shutting itself in with proprietary drivers and staying away from any sort of modding.

I ordered one the week it came out, went through quite a bit to get it through customs (for whatever reason) and paid almost twice the retail price because of it, just to be disappointed after the initial hype. Years later I thought I could use it for some stuff with the Pi, just to be disappointed again, as nothing had changed.

Since then I have been looking for replacements and I am really hoping for Soli not to take the same route.


Consider applying for YC's Summer 2025 batch! Applications are open till May 13

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

Search: