Hacker Newsnew | past | comments | ask | show | jobs | submit | Ecco's commentslogin

Ok I don’t get it. Why not register `fraser.nameˋ directly? Or pick any TLD and register ˋ a 2nd-level domain (ˋfraser.tld`)? It just feels easier, plus this way you don’t have to pay for any new member of your family?

If aaa.bbb.name is registered, then bbb.name cannot be registered.

bbb.name can ONLY be registered if it is not already registered AND there are no 3rd levels registered on bbb.name currently.

https://manage.whois.com/kb/servlet/KBServlet/faq1485.html


Not even then, necessarily. A great number of recognized personal names and surnames are proactively reserved and cannot be registered even if there are no 3LD registrations under it. I've confirmed that in the history of .name there has never been a third-level registrant under maxwell.name other than myself, and yet I was not able to register maxwell.name directly when I first got my .name 3LD in 2013.

> Or pick any TLD and register ˋ a 2nd-level domain (ˋfraser.tld`)?

How would that help? The problem is that he's losing access to all the accounts currently tied to fraser.name, if he is changing that he can just use any arbitrary domain anyways.


I mean in the first place. Now it's too late indeed.

The post sounds like that wasn't possible; that this TLD operated by exception with third-level domains. It would be like asking why you don't just register smith.uk instead of smith.co.uk: because you can't (https://en.wikipedia.org/wiki/.uk#Second-level_domains)

That's just my reading of the situation though. The person could now hope they're the first to claim their second-level domain once it becomes up for grabs, but there's probably a dozen other people with a fraser subdomain that would want the same, plus however many hundreds of scalper scum. Probably the best you can hope for is that whoever does get it, has the decency to honor the original third-level domains for a reasonable fee


> It would be like asking why you don't just register smith.uk instead of smith.co.uk: because you can't

You can. Anyone can register a .uk, and you don't need to own the .co.uk


Wikipedia says "second-level domains are managed by various government agencies, and generally more strongly controlled" besides the exceptions mentioned like co.uk. Why else would anyone ever have gone for a third-level domain?

If they've recently changed that and I'm misreading Wikipedia, that doesn't change the underlying point that the answer was "you couldn't". Otherwise I've grossly misunderstood the whole post and how verisign is proposing to cancel this person's third-level domain


There will other people with the Fraser surname in the exact same position.

Because only one lucky person can own `fraser.name` at any one time in your model. And whilst that lucky person might be able to register their family members for free. There will be countless more (unrelated) Frasers who won't be able to register (even for money) their own `FIRST.fraser.name`.

So the argument goes, society as a whole gains more if we prevent anyone from owning `fraser.name`.

A legitimate alternative though, is to register `FIRST-fraser.name`


At the beginning of the existence of the .name TLD you couldn't do that, you were forced to register firstname.lastname.name and provide an ID to justify registering this specific domain.

With it you got an email redirection from firstname@lastname.name to the address of your choice. At some point this feature was discontinued (I assume when VeriSign took control of the .name TLD), a bit after it was decided (again by VeriSign) to allow registering first level .name domain. My main email address stopped working from one day to another without me being warned in any way.

When this happened I've emailed VeriSign and my registrar at the time, and tried several time since then, to be able to register the first level domain I'm the only one using, but they categorically refuse, despite recognizing that a single subdomain has ever been registered. They kept saying that I could just let the domain expire, wait for the grace period, and register it once it's liberated, hoping that no one does it before me, and without any solution for the downtime in the mean time…

And now this… fuck VeriSign -_-


This really sounds like VeriSign has no business owning .name … best possible outcome would be transferring it to somebody who will retain the originally intended services.

It has been extreamly clear VeriSign has no business doing anaything for years.

What a perfect example of the sort of fuckery Verisign would do. You have the simplest use case and they can't even help you transition onto the scheme THEY WANT everyone to use now.

The firstname@lastname.name email forwarding is still working for me. I think only some registrars support it, though.

Really? Mine have been discontinued without notice something like 15 years ago!

My registrar, and as far as I know all registrars who support this at all, lease the 2LD forwarding address as an addon to the 3LD itself, and at rather a steep rate at that.

For some reason all the datapoints seems to be shifted a few miles south-west.


i think the mapcn package i'm using. i think it's best if change it, honestly. it got mangled up, when i started plotting a certain number of pins.


That was surprisingly both fun and somewhat serious/practical. Loved it!


:)


Yes, the joke is that this was back in 1999, but it’s funny how history repeats itself. And this gives an interesting perspective to the recent Anthropic export ban : in a way, that’s free advertising.

I wonder what commercial Anthropic could build out of this!


Using raw uncompressed bitrate is a bit disingenuous. How about comparing an older, widely supported codec like H.264 as a baseline?


If you compressed it with H.264, it wouldn't make much sense to send it remotely to be encoded with a better codec.


Why not? If h.264 is the best you can do with minimal resources, you can give it 5x the final bitrate and send it to a specialized/beefy encoding system to become something better.


> Using raw uncompressed bitrate is a bit disingenuous

It is not disingenuous given the context. Gp was responding to ggp's hypothetical:

>> Is there a compelling reason encoding needs to be done locally?


It sounds like it's electric powered. As much as I love brushless motors, I think a model of that scale and quality would have deserved actual jet engines.


Tyler Perry owns the airplane and the property. He has said that he does not fly turbines due to the fire risk in a crash. His property is surrounded by forest. If he were to cause a forest fire, the negative publicity could have a major impact on his career.


Thank you for inadvertently answering a question I had, which was who owned that estate.

I'll preempt future comments that lithium batteries can catch fire too. I agree with that statement but still think the risk is mitigated by not going with gasoline fuels.


That property is gorgeous and Tyler pulls out all the stops for his builds. That channel (Ramy RC) has quite a few of them.


The closeness of the trees to the runway kept giving me extreme pucker ...


RC-scale tiny turbines are sort of a boondoggle. They are loud, dangerous, and quite frankly reliability disasters. Expected component lifetimes are in the hundreds of hours, most folks overhaul them every 20-50 hours of use, and they fail in the air with shocking regularity (just check youtube).

It's one of those "impressive that it works at all" kind of things. If that's what you want to see in the air, then do it. If you want to watch your one-off custom plane that represents hundreds or thousands of hours of labor fly, you push it with a fan.


There is an actual airplane (multi engine) that uses these:

https://pilotweb.aero/aircraft/flight-test-colomban-jet-cri-...


Is that a physics thing, or just jet engines are hard and RC budgets aren't very big?


Mostly physics. It's hard to do small jets, mostly because small things get too heat-stressed

I sorta watched a guy trying to build a hoverboard out of 50-kgf jets, it was crazy, hilarious and didn't go anywhere because flying a backpack of kerosene on four totatally unreliable jets ain't much fun in the end. They also cost about $5K each at the time.


Just yesterday, someone posted a link to a Veritasium video[0] explaining how a jet engine internal temps of 1500°C work when the components have a melting point of 1250°C. I couldn't imagine doing that at a small scale by hobbyists.

[0]https://www.youtube.com/watch?v=QtxVdC7pBQM


Yes, and those small engines might work for a bit, but then they just burn out, this is inevitable.

If you build an A380 like here you sure don't want to use them unless you want to film it burning down spectacularly.


Sounds perfect for Hollywood practical effects vs boring CG


One can wish.

Besides, thrust control is shit even on their big brothers, on those, it was like throttle down - flameout, throttle up on the other two - flameout, oh crap, thank god we're doing tethered tests.

Gas dynamics on these scales are tricky too. Electric is the way to go for this.


I wonder if it's not a: "maintaining this kind of engine is a heck-of-a-lot of work and is why there are so many aviation regulations and the reason engine overhauls are forced and cost millions-of-dollars" kind of thing.


If it had been gas-powered motors, I would have agreed with you. The electrics sound close enough to my ear like actual jet engines though.


AFAIK the only existing small jet engines for RC planes are much too small for this one.


They've been scaling these things up over the past decade. The JetCat P1000 can exceed 200lbs of thrust.

What they really for this kind of build are RC turbofans, which are extremely uncommon. This thing puts out over 300lbs of thrust at full throttle:

https://www.frankturbine.com/en/FT1500.html


There are certainly turbines available that could power the model. He chooses not to.


How about using a format that has actually been designed to be a compressed read-only filesystem? Something like a SquashFS or cramfs disk image?


When looking at established file formats, I'd start with zip for that usecase over tarballs. zip has compression and ability to access any file. A tarfule you have to uncompress first.

SquashFS or cramps or such have less tooling, which makes the usage for generating, inspecting, ... more complex.


You only have to decompress it first if it's compressed (commonly using gzip, which is shown with the .gz suffix).

Otherwise, you can randomly access any file in a .tar as long as: - the file is seekable/range-addressible - you scan through it and build the file index first, either at runtime or in advance.

Uncompressed .tar is a reasonable choice for this application because the tools to read/write tar files are very standard, the file format is simple and well-documented, and it incurs no computational overhead.


You've just constructed your own crappy in-memory zip file, here. If you have to build your own custom index, you're no longer using the standard tools. If you find yourself building indices of tar files, and you control the creation, give yourself a break and use a zip file instead. It has the index built in. Compression is not required when packing files into a zip, if you don't want it.


Yeah it's pretty common to use zip files as purely a container format, with no compression enabled. You can even construct them in such a way it's possible to memory map the contents directly out of the zip file, or read them over network via a small number of range requsts.


> Uncompressed .tar is a reasonable choice for this application

Yes, uncompressed tar (with transfer compression, which is offered in HTTP) is an option for some amount of data.

Till the point where it isn't. zip has similar benefits as tar(+transfer compression) but a later point where it fails for such a scenario.


Zip allows you to set compression algorithm on a per-file basis, including no compression.


You can achieve the same with tar if you individually compress the files before adding them to the tar ball instead of compressing the tar ball itself.

I don’t see how that plus a small index of offsets would be notably more or less work to do from using a zip file.


Zip has a central directory you could just query, instead of having to construct one in-memory by scanning the entire archive. That's significantly less work.


I mean if they include a pre-made index with it. For example an uncompressed index at byte offset 0 in the tar ball that lists what is inside and their offsets. It would still be comparable amount of work to create software to do that with tar as to use a zip file, if fine grained compression levels etc is being used.


But then you are not using tar, you are doing your own file format atop of tar.


I suppose you are right about that. But it would still be a valid tar file that can be viewed and extracted with normal tools. Kind of similar to how a .docx file can be extracted as zip but still has additional structure to its contents.


What are you really proposing? That a first ".INDEX" entry be made that contains the offsets of all the other members?

That could work in a backwards-compatible way (as long as no standard tar utility makes modifications to the archive...), but it's hamfisted. Just use Zip. It's already a well-known format with numerous implementations and already does the job that you want to do.


Romfs is more capable, simple to support, and doesn't have the overhead of tar's large headers and typical large blocking factors.


Zip is a piece of cake.

I had need to embed noVNC into an app recently in Golang. Serving files via net/http from the zip file is practically a one-liner (then just a Gorilla websocket to take the place of websockify).


I second the idea to use a zip. In fact it's what a lot of vendors do because it is so ubiquitous, even Microsoft for example - the "open Microsoft Office XML document format" is just a zip file containing a bunch of folders and XML files.


Sometimes (read: very often) you can’t choose the format. Obviously if squashfs is available that is a better solution.


Because their use case was to support existing tarballs of code.

The problem they’re solving is literally right there in the article you didn’t read.


Reading the article is what made him say that.


Kinda ironic that standardebooks.org refuses non-English books but will happily promote a French ranking... I mean none of those books are actually available on standardebooks.org - at least not in their original French version.


Good to know that they don't have the original French version of Brave New World


That is really cool. I wish it had an animated video to display the result, that'd be even easier to follow and therefore even more impressive.


Maybe possible with that DSL the YouTube channel 3Blue1Brown created?


Manim


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

Search: