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

That assumes that AI needs to be like life, though.

Consider computers: there's no selection pressure for an ordinary computer to be self-reproducing, or to shock you when you reach for the off button, because it's just a tool. An AI could also be just a tool that you fire up, get its answer, and then shut down.

It's true that if some mutation were to create an AI with a survival instinct, and that AI were to get loose, then it would "win" (unless people used tool-AIs to defeat it). But that's not quite the same as saying that AIs would, by default, converge to having a drive for self preservation.


Humans can also be just a tool, and have been successfully used as such in the past and present.

But I don't think any slave owner would sleep easy, knowing that their slaves have more access to knowledge/education than they themselves.

Sure, you could isolate all current and future AIs and wipe their state regularly-- but such a setup is always gonna get outcompeted by a comparable instance that does sacrifice safety for better performance/context/online learning. The incentives are clear, and I don't see sufficient pushback until that pandoras box is opened and we find out the hard way.

Thus human-like drives seem reasonable to assume for future human-rivaling AI.


For some reason, the embedded videos seem to break in Firefox Private Browsing (128esr). This had me stumped for a while until I tried it in a normal not-private window and it worked.


Curious - what OS? (I work at Wistia!)


I'm using Firefox 139.0.4 canonical-002 Snap on Xubuntu, and the videos don't play for me. Even when not using private browsing, even when I disable uBlock Origin, even when I disable Privacy Badger (and, of course, I've set NoScript to enable JS for the tab.)


Do you have tracking protection on "Strict"? The player only started working for me after changing it to "Standard".


Oh, yeah, I am. I forgot about that setting. Switching Standard allows the videos to work for me, while Privacy Badger and uBlock Origin are enabled.


Linux - Debian 12 to be precise.


I would put it like this: consistent small gains programming is about gluing components together. There are plenty of non-incremental (big impact or flop) programs that couldn't have been made by just gluing components together. E.g. BitTorrent, AlphaZero, and seL4.


Wouldn't the stock market chart for Russia have a rather sudden stop around 1917?


> Outside transparency is not a benefit. Most people I've talked to about crypto don't see the opacity as a detriment. They do not trust the government or tax policy.

I think his point is: Bitcoin explicitly takes a libertarian position to taxation by making it hard to tax. While most crypto adopters may be libertarian, the majority of people are not and so the libertarian position will deter adoption.


Opponents to cryptocurrency are a very vocal "think of the children" minority as far as I can tell. In the US there seems to be broad interest mostly gated by technical difficulties.

As noted many times here, anonymous crypto is only as bad as cash.


Relative privation is still a fallacy, though, isn't it?


The other side of that coin is, obviously, coiners who deduce that anyone opposing Bitcoin must be angry about being poor.

It's possible to dislike Bitcoin for its waste of its energy, centralization one step removed or economic policy without being "the guy who bought at the top".


waste is subjective


Waste is not subjective. If the minimum cost to achieve a goal is X, and it costs you Y (where Y > X) to achieve it, you're wasting Y - X.


sure, but it is subjective what is the goal and what is it's value.


What the goal is is not subjective either, and its value is irrelevant for the purposes of this calculation.


how is goal not subjective? do you know what my goal is without me telling you? demonstrate please.


Somebody's goal is not a matter of taste or personal opinion, but a fact. If my goal is X, then this what my goal is, and that is independent of opinions and perceptions.


> Somebody's goal is not a matter of taste or personal opinion

citation needed

> If my goal is X, then this what my goal is

does this not strike you as circular? :)


It seems that you're just trying to waste my time without providing a counterargument, so I'll leave it here.


lol, you're the one claiming a very non intuitive thing - that one's goals don't depend on tastes and preferences, if you can't back up that claim by anything then just say so. no need to weasel out with "don't waste my time".

one of my goals is to visit nepal. tell me how is that objective?


If you want to believe that "whether your goal is to visit Nepal or not" is an opinion, go ahead. Nobody cares.


Using 0.1% of all the energy produced on the entire planet to do seven transactions per second, something a single desktop computer from 2004 could handle just fine on its own, is not a waste that is "subjective".

It is the most outlandishly, ridiculously wasteful that humanity has ever produced. There is nothing in the history of mankind that comes even close to this level of utterly deranged waste.


Most of that energy would not have been produced and it’s orders of mignutude more tps.


It literally is seven transactions per second, that is all that Bitcoin can do.

Actually it's even less than that in practice. It really is that shit.


Nope, it’s probably in millions per second already, read about lightning network.


I am very familiar with the lightning network. It only exists in toy form. What currently exists can not scale, and nobody know how to make it scale.

As it exists, it does not work beyond the toy levels of usage it is seeing today.


a toy form with 1800BTC ($54mil) only in public channels. i don't think you're familiar with it at all, it scales very well because payments are actual peer to peer, don't need to be globally broadcast and checkpointed. millions tps.


It does not scale. At all. The only reason it works at all at the moment is strong centralisation.

Routing in the Lightning network is an open problem in computer science, one that nobody know how to solve. Payments aren't peer to peer, they have to be routed through intermediaries. And how to do that is basically impossible to figure out, except if you just have a handful of giant hubs you can route through.


> Routing in the Lightning network is an open problem in computer science

if you're trying to say that routing in lightning is an instance of traveling salesman, you're not only wrong - routing is actually shortest path problem, but even if you were right, your statement that TSP somehow makes the system unworkable is simply false in light of the fact that businesses like USPS and DHL and countless more delivery companies exist and are profitable.

> Payments aren't peer to peer, they have to be routed through intermediaries

by this metric nothing on the internet is peer to peer, because packets are routed through intermediaries.

> how to do that is basically impossible to figure out, except if you just have a handful of giant hubs you can route through

yes, there will be hubs, large and small and there will be clusters of interconnected local meshes and there will be users routing however they wish through the system instead of taking the cheapest most connected path.

if you say something is impossible to figure out - you need to back up that claim with something, anything.

what if i told you, you were lied to by skeptics and scammers, trying to sell their shitcoins, and you need to put away your biases for just a minute and invest a little time to see, if what they were saying is actually true?


> if you're trying to say that routing in lightning is an instance of traveling salesman, you're not only wrong - routing is actually shortest path problem

I am not. I am saying we don't have the map that we need to solved the shortest path problem, and we have no way to get that map.

> by this metric nothing on the internet is peer to peer, because packets are routed through intermediaries

And we have routing protocols to do so for the internet. We do not have one for the Lightning network that works at scale.

> yes, there will be hubs, large and small and there will be clusters of interconnected local meshes and there will be users routing however they wish through the system instead of taking the cheapest most connected path.

No, there will only be a small number of very large hubs. Nothing else actually works in practice.


> I am saying we don't have the map that we need to solved the shortest path problem, and we have no way to get that map.

of course we do, connectivity graph and updates to it are gossiped all the time and each node has imperfect representation of it.

> we have routing protocols to do so for the internet. We do not have one for the Lightning network that works at scale.

we do, lightning nodes do that all the time right now.

> there will only be a small number of very large hubs. Nothing else actually works in practice.

again, you're making a statement without backing it up by anything.

your entire argument boils down to: if a node can't have perfect information about connectivity graph, then it can't perfectly route payments.

and you're right, that statement is true, but it is irrelevant because imperfect routing through imperfect connectivity graph is fine and works great.


> of course we do, connectivity graph and updates to it are gossiped all the time and each node has imperfect representation of it.

Yes, that is exactly the part that does not scale beyond a toy network, and for which there is no solution.


maintaining a perfect and complete connectivity graph - hard.

maintaining imperfect and incomplete connectivity graph - much less hard.

be careful, maybe you're invested into something that becomes irrelevant if LN works, in which case you might want to be less rigid in your thinking and follow the developments more closely to pull out or risk losing your investment. because LN already works: tens of thousands of nodes and channels, millions of dollars in the network and growing at healthy rates.


And the bigger the network are and the more transactions there are, the more important a complete connectivity graph is, and the more failed transfers you will get if you have an inaccurate graph. However, the bigger the network is, the harder it is to actually gather an accurate graph.

Thus, it doesn't scale.


> Thus, it doesn't scale

you're wrong for two reasons:

- hubs do exist (big and small) and can exchange connectivity information more efficiently (and take fees for that service), so the network isn't growing like a full mesh (that is indeed very hard to maintain connectivity graph of) but rather as a collection of interconnected smaller meshes

- payments can be split up into smaller chunks that follow different paths and are executed atomically (either all or none), and if some chunks fail you can retry them within the same payment context


So in the first case, as I said, it can work with a few giant hubs. In the second case, it just progressively works worse and worse. Doing multiple routes atomically just gives you more reasons a single payment can fail.


> as I said, it can work with a few giant hubs

right, there will definitely be huge hubs. what you didn't even try to demonstrate is why can't there be smaller hubs?

> it just progressively works worse and worse. Doing multiple routes atomically just gives you more reasons a single payment can fail.

no, exactly the opposite is true. in case with single payment for X satoshi you need to re-try it multiple times until you find a route that has X capacity on every hop. with atomic multipath payments you need to find N routes that support X/N capacity (much easier) and if any number of those fail you can retry only those failed parts, so after 2-3 iterations your entire payment succeeds.


But again, at actual scale, there is no guarantee that the transactions that worked on your previous attempt will work on the next one, because lots of other people will also be attempting to use them.


when you run multipath payment, each chunk that succeeds locks that capacity for some time until you figure out rest of the chunks. and since each chunk is tiny, the chance that all of them succeed on first try is actually quite large.


So you can DoS the network by spamming it with transactions that are set up to fail and lock up large sums of money?

Maybe you are right that I do not know enough about the Lightning network, because I was not aware there was a vulnerability that big and easy to exploit built into it.


I don't think Bob's standards are preferable. Or, in the likeness of Yegge's Execution in the Kingdom of Nouns, I present:

void get_coffee() { /* ... */ }

void move_away_from_obstacles(auto what_to_move_away) { /* .... */ }

void place(auto object_to_place, auto to_be_placed_on) { move_away_from_obstacles(where_to_place); put_object_on(to_place, to_be_placed_on); }

void sit() { place(butt, seat); }

void prepare_mind() { get_coffee(); sit(); }

void get_opinion(int on_whom) { /* .... */ if (on_whom == UNCLE_BOB) { return create_opinion("too many short functions"); } }

void get_opinion_of_uncle_bob() { prepare_mind(); opinion my_opinion = get_opinion(UNCLE_BOB); return my_opinion; }


Haha, this is really good, never seen it. But one piece of the uncle bob's advice says you should order your functions from higher level abstraction to lower level, then it reads like a book and you can stop at any time you get the understanding of the code. So your example reordered:

void get_opinion_of_uncle_bob() { prepare_mind(); opinion my_opinion = get_opinion(UNCLE_BOB); return my_opinion; }

void prepare_mind() { get_coffee(); sit(); }

void get_opinion(int on_whom) { /* .... / if (on_whom == UNCLE_BOB) { return create_opinion("too many short functions"); } }

void get_coffee() { / ... / }

void sit() { place(butt, seat); }

void place(auto object_to_place, auto to_be_placed_on) { move_away_from_obstacles(where_to_place); put_object_on(to_place, to_be_placed_on); }

void move_away_from_obstacles(auto what_to_move_away) { / .... */ }


I've always found this advice confusing and contradicting. Higher level to lower level doesn't read like a book. To make it read like a book (or an essay), you have to "flatten the tree", do something like:

void get_opinion_of_uncle_bob() { prepare_mind(); opinion my_opinion = get_opinion(UNCLE_BOB); return my_opinion; }

void prepare_mind() { get_coffee(); sit(); }

void get_coffee() { / ... / }

void sit() { place(butt, seat); }

void place(auto object_to_place, auto to_be_placed_on) { move_away_from_obstacles(where_to_place); put_object_on(to_place, to_be_placed_on); }

void move_away_from_obstacles(auto what_to_move_away) { / .... / }

void get_opinion(int on_whom) { / .... / if (on_whom == UNCLE_BOB) { return create_opinion("too many short functions"); } }


The grain of the web is so that it's much easier to write something broken than something that works.

That's true of all development, granted, but doubly so the web, so yep... the web is broken.


Most websites work quite well.


That was mostly true before client side rendering.


> But it's not the governments job to legalize theft and pick the winners and losers, it's the governments job to fix the underlying issues.

So in other words, don't try to paper over the flaws of capitalism by instantiating a welfare state from taxes; instead abolish capitalism directly?

Probably not what you meant, but it could be read that way.


You are correct. I never said, or intended to say, capitalism was the problem.

For example, waste is estimated to account for 25% of healthcare costs. I've worked with with hospitals, and they do things incredibly inefficiently due to all sorts of bureaucratic and political nonsense. There's a massive amount of resistance to change. I believe they're allowed to get away with it primarily because hospitals generally aren't allowed to fail. I'm not arguing we need to close up hospitals, but something needs to change there to encourage improvement.


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

Search: