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

Many languages will die before being digitized if they have to wait for 20-25 years


I saw this at my last company. Even worse breaking it into microservices allowed teams of 2 or 3 to start building entire realms where only they could commit and used it for internal politics.

I witnessed someone that wanted to leverage their service into a promotion so they started pushing for an architecture where everything flowed through their service.

It was the slowest part of our stack and capped at 10tps.


Why do you believe that?


Yeah the first version looks like something that many people would try to 'optimize' but in reality it is extremely readable and should be very easy to change/extend.


> And I would find it interesting to be able to claim that magic leap has sued me for distributing 3 month old api docs to myself.

Do you have that much money to burn?


> What if we were to set up a project in response to this that made the Magic Leap API docs available in a distributed fashion?

If your name is still attached you will still get these letters. Because they will continue to try and show they are protecting their IP.

> As well as a technical breakdown of everything that can be learned from them.

Then that would be your IP which you'd be free to distribute. You won't receive the same letter again, but you may be breaking an NDA and the terms of which may apply.

Why do you think that ipfs and/or blockchain is going to change how copying IP works?


I've only found yelp to be trust worthy in some cities, not universally.


I've found yelp to be completely untrustworthy, in every city, everywhere. What people think in the aggregate and what some individuals think are very different things.


That fails for the case that you have an appointment at 3pm in 30 days, and 15 days later the timezone's offset changed.


How does that fail? I have an integer for an appointment. I am at that appointment at that given integer. This applies for all timezones. If the timezone changes, the integer does not. What you are saying is that the timezone changes and the integer changes aswell, but then it's not the same appointment anymore.


Your integer is wrong because it was computed by translating from the current offset of the timezone. What we are saying is that the timezone definition might change in the future (ex. Government no longer honor DST). At that point when you translate back your timestamp into local time it no longer matches the original schedule that the user set.


But the integer stays the same. That's the main point here. Everything else is just converting it to local time. Sure timezones might change that.


From the user's perspective it is the same appointment. They think they have an appointment at 3:00 PM on Thursday. If there's a timezone change, and you just stored an integer, then from the user's perspective the meeting changed from 3:00 PM to 2:00 PM.

Of course, if you have a meeting that spans timezones, this is unavoidable. I think the real solution actually lies in how the meeting time is expressed to the user so they don't have misconceptions about it.


You won't really be able to process tx that low, you'll need to pay a tx fee proprtionate to the number of bytes. 1 satoshi per byte is a good rule of thumb for a very cheap tx. It takes more than 1 byte to describe one satoshi, so you can't get your tx to propagate.


Theoretically the attacker could also be picking up 0-fee transactions, but my intent was to really say this: it doesn't matter how small a double spend is - the ramifications for the network are the same.


Yeah in the next couple years I'd expect to start seeing smaller PoW chains wither away due to attacks like this and exchanges starting to have prohibitively high conf times as they'll need to protect them selves from attacks like this.

Merchants are probably fine.


Consider applying for YC's Spring batch! Applications are open till Feb 11.

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

Search: