nirui

articles about AI making money, that is.

Problem is, the gain in performance to an user maybe negligible compare to the pain that the device purchased might never be able to be fitted to run some application.

I wouldn't say "should be", but HBM could indeed benefit the end-user somewhat, like @15155 already pointed out. And that benefit could be used as justification for soldered HBMs on future computers.

BUT... a smart consumer would also recognize the other side of the story: do we really need HBM on consumer devices? We don't serve 1000 users at the same time, a slower, cheaper device is good enough for most use cases (including the professional ones), better if it's also somewhat future-proof. After all, smart people usually have better foresight.

In this market, CXMT is more likely to also move to HBM production rather than consumer grade RAMs. After all China is also doing an AI push in a competition with the US, and the domestic Chinese companies are "recommended/guided" by the government to help, while consumers are pushed to lower priorities.

The situation I'm worrying about is that these PC manufacturers could use this opportunity to push for a more locked-down design, such as soldered RAM or even SSD. My current ThinkPad already got soldered LPDDR5 RAM chips on it with no user-end RAM upgrade possible, so there's a reason to suspect they'll take more pagers from Apple's book if they can get away doing it, just like what they did when they pushed out those internally mounted unswappable batteries.

My personal guess is that the RAM price will fall down after this period of AI expansion is over and major players starts to consolidate. But it will not fall as much as we're hopping for, because the manufacturers could just reduce production to control the price.

> Focusing on profit within the next few quarters, and not caring about the longer term consequences

Anything new? From my non-American view, American companies has done similar things for a very long time now. It happened in the consumer electronics, it might happen again in the IT industry.

It's not the fault of the companies, they simply just wanted more certainty and the consumer market is not (when compare to cooperate contracts).

But from the stand point of a nation, if no one creates low-end products, then no one will be providing low-end/entry-level jobs. That's when you got structural problems.

The problem I think is that current LLMs maybe not complex enough to accept all stimulation.

Current LLM systems are more like simulation of the stimulation, a conclusion rather than a exploration.

I'm feeling people are using AI in the wrong way.

Current LLM is best used to generate a string of text that's most statically likely to form a sentence together, so from user's perspective, it's most useful as an alternative to manual search engine to allow user to find quick answers to a simple question, such as "how much soda is needed for baking X unit of Y bread", or "how to print 'Hello World' in a 10 times in a loop in X programming language". Beyond this use case, the result can be unreliable, and this is something to be expected.

Sure, it can also generate long code and even an entire fine-looking project, but it generates it by following a statistical template, that's it.

That's why "the easy part" is easy because the easy problem you try to solve is likely already been solved by someone else on GitHub, so the template is already there. But the hard, domain-specific problem, is less likely to have a publicly-available solution.

You're talking about a company owned by one of the richest "tech bro" out there. He's not just an ISP, he's a visionary (for better or worse) with a lots of ideas.

TLS payload is encrypted, but meta data (such as SNI and other fingerprints) is not. These meta data could still be valuable for someone who know how to utilize it.

Not sure about that too, the market is just too delicate at current moment.

People renting VPS to do something, running a service, a website, email etc. But there are other ways to achieve the same without the need of a VPS.

If VPS cost increase to a certain level, some people will just host the service on their own Raspberry Pis through Cloudflare Tunnel, or just simply shut the service down.

I doubt that.

Some dirt-cheap VPS maybe too unreliable to run anything serious, that's why they sell that for dirt cheap. And their consumers generally won't complain about sudden server reboots, because that's what expected for the price.

If they increase their prices, then many of their customers maybe better off just use Linode or DigitalOcean etc instead, as these vendors provides better guaranty on stability.

Unlikely. What's more likely is that they just simply don't care. They have turned this into an arms race now, killing off competitors is much more important than caring about coastal damage or even their own future.

But this does highlight the fact that most of our hardware is produced (and thus can be restricted) by a few cartel-like players, just like what's happened in the Internet industry.

> any random enemy with hardware access could plug in a USB cable, flash the older exploitable signed firmware, steal your personal data, install a trojan, etc

A lot of my phones stopped receiving firmware updates long ago, the manufacturer just simply stopped providing them. The only way to safely use them is to install custom firmware that are still address the problems, and this eFuse thing can be used to prevent custom firmware.

This eFuse is part of the plot to prevent user from accessing open source firmware, it's just that. Your "user safety" jargon cannot confuse people anymore, after all the knowledge people (at least the smart few) has learned during the years.

Wrong.

The definitive factor here is whether the Chinese company wants to put themselves deep in the American political water. To any company, living under a crosshair alone is difficult enough, it becomes even more so when the company is foreign-owned.

The sell was a strategically correct decision by ByteDance, they made money out of it and they secured some future income, at least for a short while. But no app or service lives forever anyways, so it's still a good trade.

Whether or not the sell could benefit actual American users was never mattered.

Why so self-defecting? Even some of the job could be out-sourced, some positions just cannot. If those people can unionize, it might starts to grow from there.

It's like planting the seeds, it might not work from time to time and from places to places, but sometime the result might surprise you. But you'll never know if you don't give it a try.

It's like... (maybe an inappropriate example) how NRA brainlessly defending gun rights. They don't first spend 500 billions on gun safety research trying to prove gun is safe, no, they want guns, and then they come up reasons why guns are good.

In the recent years I'm started to think maybe this NRA-style method is actually how to set things in motion (if it's not the only effective way), as any added prerequisite or cations may eventually bog things down to a stop. You all read the CIA sabotage manual right? There's a chapter detailed how you can stop a plan by adding complexity (i.e. bigger committees etc).

Hmmm... Got me thinking, why must all software implement (and maintain) transport security?

The security standard changes/improves over time. With software like stunnel takes care of it, your software could be practically security wise up-to-day forever as long as you or your user keeps their stunnel updated.

Was a Nova user, moved to Lawnchair yesterday. It's not the same experience I got from Nova (for example, the Clock widget don't work), but the adaptation is not unbearable.

I purchased Nova Launcher Prime years ago thinking it was the best investment I put on Google Play, well, maybe I should've spent the money on something else.

I don't remember the T480 I had was any slow, except of course when running games. So I do agree that the machine is still capable for most use cases today.

But I also saw people (usually X series users) complaining on YouTube saying something like their "mobile" CPU is trash etc. My thinking is, if the slowdown is actually insignificant for real-life use cases, then I rather have longer battery life than better performance.

I'm curious how much slowdown a "weak" CPU can cause for real-life programming task, assuming the CPU is at least gen 4 Intel.

I never used a mobile/power-efficient CPU myself, but I do use old CPUs. For example, this I5-4210M on my T440p, it's obviously not fast compare to newer ones, but when writing code on it (Go and a bit of Rust), I don't really feel a day-or-night level difference. Sure, it's slower, but not unbearably, in fact for most cases I barely notice it.

I think we've wasted a lot of time on this.

> Personally, I value my code compiling in the future over more explicit error handling. New errors will hit my catch-all branch, and I can special-case them later as I see fit. But it's a philosophy/values thing.

OR, you can just do `fn() MyError` then `if myError := fn(); !myError.OK()` opposite to just `fn() error`. I actually use this "trick" on many of my projects and they worked great.

I'm not really sure why Go defenders MUST praise Go's error handling as if it's flawless and thus all fault signals must be a `error`. As I pointed out few comments back, Go is clearly promoting binary error handling i.e. `if err != nil { return error }`, as doing branched out handling for specific error type is much harder (one example is the "nightmarish manual type discovery" mentioned above), so it's far from flawless. It's useful, sure, and people are using it, but it's not flawless.

BTW:

> I can special-case them later as I see fit

See? You already doing manual type discovery, they slipped the idea so naturally into your brain you don't even notice the struggle. But what if the number of types that you need to take care of keeps growing? Is it scalable?

You know what, maybe they should add Sum type for error handling. Hope it's not too late now since many people already camped on the idea that returning an interface then and casting it for error handling is the best idea ever.

> In reality copper is just convenient. We use it because it's easy to work with, a great conductor, and (until recently) quite affordable

It's convenient, it's easy to work with, great conductivity, and cheap enough all at the sametime... Dude, I think you just explained why cropper is used instead of anything else.

> If I'm understanding you correctly, you can implement your example in a fully idiomatic way, and the stdlib does this in a bunch of places.

I don't think you understood my point. Instead, I believe you launched your argument too quickly. Because if you continue reading, you'll see:

> ... but if you want to so the same in Go, there will be a nightmarish manual type discovery and tracking operation waiting for you.

Which should deter you from providing the example where you declared the `ErrFoo` and `ErrBar` type, since it's basically the "nightmarish manual type discovery" scenario unfolding in basically realtime.

But let's continue with the example to make my argument more full:

Let's say one day the `ErrFoo` and `ErrBar` type is not sufficient, so you declares another type `Err2000`. Now what happens down stream?

Since the some function may just return an error interface, there's no way for the end user to know you've added that error type. From their prospective, everything is unchanged, and still compiles just fine.

If the user's code is relying on the exact error type for branching, then they have to perform "manual type discovery and tracking" to monitor the changes to your code (and everything above it, really) to ensure that the branching is still done correctly.

In Rust however, since error is a emun, all error conditions must be handled or explicitly ignored during a `match`, if you write something like

    match File::open("filename.txt") {
        Ok(file) => {}
        Err(io_err) => match io_err.kind() {
            ErrorKind::IsADirectory => {} // Notice how not every error type is handled
        },
    }

The compiler will just stand up and make your ass weep. Meaning if you add some new error conditions, your user will know that for sure when they compile.

(BTW, `std::io::ErrorKind` is indeed `non_exhaustive`, but you the maker of the error type still have to explicitly/intentionally declare it to make it non_exhaustive)

So, let's read my comment again:

> Rust's error handling encourages such branched out handlings by default, but if you want to so the same in Go, there will be a nightmarish manual type discovery and tracking operation waiting for you.

(Also, "by default" is there to indicate that yeah you can boxing a `std::error:Error` trait in Rust, then you ended up with something like how Go handles error. I know.)

Funny enough, based on my observation, X (formerly know as Twitter) is more likely to ban/shadowban normal users who has weak engagements than algorithm-optimized bots.

A lot of bots are posting pornographic content or selling illegal items on that platform. And since many of the bots are "verified", it is harder to filter them out completely. The whole thing is a mess at this point.

> e.g. net.OpError

I have my own complain against Rust's error handlings, but I can't bring myself to praise what Go has been doing.

One problem with the error interface is that you can't know exactly which error type will be returned, and the Go authors may add new error types form time to time. `net.OpError` itself is a great example for that, which is a newer type than net.Error.

This style of error signalling is best used when the error handling is binary, either "No error, continue" or "Errored out, abort", but not branched out path like "If encountered error A, do this. If encountered error B, do that. Otherwise, abort".

Rust's error handling encourages such branched out handlings by default, but if you want to so the same in Go, there will be a nightmarish manual type discovery and tracking operation waiting for you.

So for me, I rather use a dedicated signal code to tell which error branch I should do next rather than relying on the error, i.e:

    if next, err := func(); err != nil { // If errored, abort it
        return err
    } else if next == condition1 {
        return op1()
    } else if next == condition2 {
        return op2()
    } else {
        panic("unsupported condition")
    }

What kind of visa Mr. Maduro was using when he entered the US?

I'm guessing it must be very good since, let's just say he kinda fits the profile which President Trump might describe as "worst of the worst", and yet the US Customs still just letting that guy walk right in.

But anyhow I hope Mr. Maduro don't illegally overstay because if ICE found out about it, there's a chance they'll deport Mr. Maduro to Venezuela.

Oh yeah, the Internet... is was very hard to get things set up if you changed one file and then it turned to a command prompt with no possibility to access a browser, LOL.

Now days when the same thing happens, you could just grab the Internet phone located right in front of you and search away. Technology really changed life.

I'm watching the price refresh since last year, hoping the domestic manufacturers in China could rebalance the price a bit. Nope, it turned out that did not happen. It's a free money grab right now of course they raised their prices.

But I guess Americans will not be buying Chinese RAMs/SSDs for critical applications (such as AI), and not a lot of user outside China will use Chinese AI due to restrictions such as censorship etc being enforced on it, limiting the growth and scale of the tech. So, there is still hope that some of the manufacturers will eventually pivot towards tried and true consumer products.

That brings back my memory (again) installing Mandriva on my old old old computer which has a NVIDIA TNT2 graphics card. It was a completely nightmare back then to install driver for it in order to get it to output at the correct resolution and refresh rate...

Now I have a Thinkpad T440p with a GeForce GT 730M dGPU which NVIDIA no longer provide driver for newer Linux kernels, so I have to use slower nouveau driver.

Ah, something never change.

> Your friends with kids still want to see you.

If you both have kids, then the kids may also want a chance to socialize. Meeting new people with their parent is a great opportunity to expand their social network and learn how they should act in front of friendly people.

Of course, the parent needs to be smart about it to avoid or correctly correct the negative sides, but assuming you're a good parent, a well-socialized kids will grow up differently in many better ways than a completely home-breed one.

Checked out as instructed, it somehow made me empathetic towards the OP. Not only the business completely harmless, it's the opposite: their job is trying to make people happy, and it's lovely.

Off-topic reply but I don't want to start another comment:

The problem about Google and AI has deeper layers: AI answers has trained users to not look into the source information (a.k.a websites), and websites are combating it by making themselves harder to crawl (for example, by enabling Cloudflare protection/verification), which in turn makes creating new search engine harder.

This down circle is currently unbreakable, which is a hellish situation for new comers, but great for established players such as Reddit, Facebook etc since they have internal search engine as well as mountains amount of content to provide.

If one day the big platforms (there are only handful of them) completely blocked Google from crawling them, that will be the true death of Google.

It is more useful to know what exactly you're writing beyond the description of "business logic and real world problem".

For example, writing UI components maybe easier on some language than writing abstract algorithms, writing standardized solutions (i.e. text-book algorithms, features, etc) is easier than writing customized algorithms, etc.

Also, writing code can be very fast if you don't unit test it, especially for CURD apps. In fact most of my coding time was spent on writing unit tests.

I really hoped AI could write those tests for me to lock the specs of the design completely down. But currently it's the opposite, I have to write test for AI generated code. So, my over all experience can be described as the tyranny of reading other people's code times 10.