In USSR similar adage was: “No matter how much you steal from the State, you can’t get even.” (Сколько у государства не воруй — все равно своего не вернёшь.)
No, there is a in-world reason at least for no drones. Wikipedia:
> However, a great reaction against computers has resulted in a ban on any "thinking machine", with the creation or possession of such punishable by immediate death.
tl;dr - Machine intelligences existed in Dune history, were discovered to be secretly controlling humanity (through abortion under false pretenses, forced sterilization, emotional/social control, and other ways), then were purged and replaced with a religious commandment: "Thou shalt not make a machine in the likeness of a human mind"
No, and there is a (piloted) drone attack in the first book -- Paul is attacked by a hunter-seeker.
The reason nobody tries to use the lasgun-shield interaction as a weapon is because the resulting explosion is indistinguishable from a nuclear weapon, and the Great Convention prohibits the use of nukes on human targets.
Just the perception of having used a nuclear device would result in the House which did so becoming public enemy #1 and being eradicated by the Landsraad and Sardaukar combined.
@Potro: If you liked the movie, read the books. I don't read a lot anymore, but during sick leave I started with the first book. Didn't stop until I finished the main story, including the sequels by Frank Herbert's son about a month later. That's like... uh... nine books?
In the book Paul is attacked by an insect drone while in his room. The drone was controlled by a Harkonnen agent placed weeks in anticipation inside a structure of the palace so it was also a suicide attack as the agent had no chance to escape and would die of hunger/thirsty if not found.
It’s quite amazing to find a post with close to zero substance (not my intention to offend its creator who submitted it) from some blog on some hosting platform with total of 2 entries (the other one is extended “Hello, Word”) to get meaningful time on top of the site, and generate some extended discussion.
How it works?
The irony is, I think I could get more delivered with a $670k cheque than I could with a $6.7 million one. With the latter, you would grow too big, management would creep in, you would overengineer, you might spend too much time working behind closed doors etc.
Later on you would need cash to scale this business, but for early stage product development I think $500k to $1 million is the sweet spot.
Also since Kagi is a paid product, I imagine that the amount of external funding needed is inherently less than a startup that is built on the "scale first, monetise later" model.
I imagine that their hosting costs must be quite big and not very elastic. Crawling takes compute and bandwidth, storage cost will be high, as you need to store data in low latency storage, then indexing which is more compute costs.
They may have access to talent pool willing to work for their vision at significantly reduced rates, but unless they effectively sell themself to big cloud provider, they can’t significantly reduce the infrastructure cost.
> A distinctive feature of Zig is that it does not deal with memory allocation directly in the language. There is no malloc keyword like in C/C++. Instead, access to the heap is handled explicitly in the standard library.
I guess it is all you need to know about the article quality.
The point that paragraph is trying to make but articulates imperfectly is that you explicitly pass an Allocator to the stdlib routines that allocate -- rather than having them allocate on the heap implicitly.
Yes, but it still is a part of the standard library and how the standard library does things - a convention. Same as in C, as malloc is just a function. You could create a replacement library for C stdlib and it could also expect an allocator in the parameters if a given function could allocate.
>Yes, but it still is a part of the standard library and how the standard library does things - a convention. Same as in C, as malloc is just a function.
Yes, but it doesn't argue that it's not the same in C. Just that it's not the same as languages who do the memory allocation themselves.
>You could create a replacement library for C stdlib and it could also expect an allocator in the parameters if a given function could allocate.
You could do anyting in C, even write Zig in it. And vice versa, you co do malloc in Zig. But allocators are how Zig is designed/used, whereas C opts for malloc.
Their standard libraries are built around the notion, but I would argue that putting allocation in their respective stdlibs instead of a part of the language makes it possible to be flexible if needed. There are non-trivial and semi-popular C programs that do not use the C stdlib at all.
I agree that the culture is different and that is significant, but I do not see it in the notion of the language itself (without its stdlib).
Also what is idiomatic for Zig does change as it is not a mature language. Though the allocator passing is expected to remain. Odin did an interesting thing and the allocator is put in a 'context' which is an actual part of the language.
It would be hard for a replacement with the purpose of modernizing a way of working to be idiomatic at the same time. It would be an explicit attempt to update what is idiomatic, and of course not be the same as what was before.
It's actually a rather interesting idea, if I had the time for a C-focused side project that sounds really fun! :)
It's not quite as clear-cut, some stdlib modules take an allocator when an 'object' is created (containers mostly work like this), others on each function call that needs to allocate (but crucially, one way or another, an allocator needs to be passed in).
In any case it's not nearly as limiting as the 'red-blue' async-await color split in other languages, and I can't think of a single downside of explicitly passing allocators into stdlib modules instead of having a hidden global allocator.
The approach to always pass allocators isn't all that Zig specific either, it's also a good library design practice in pretty much all other languages which allow explicit memory management.
No, I wouldn't describe it like that. It's more that there isn't an ambient, implicit Allocator lying around for stdlib to use. It is explicitly provided by callers.
If you want to think of it that way, the stdlib `voluntarily` colors its functions by allocator. You can do whatever you want in your own functions, including always using a global allocator and never passing it anywhere.
Well, you have expicit allocators. A popular branch of the field calls this ‘dependency injection’. It's true that the current standard library never allocates implicitly, because that would be bad on constrained projects, but there's nothing stopping you from writing code that does so, or presumably even using libc.
In case of Amazon just stop selling devices or increasing their price will reduce usage and cost.
For both Amazon and Google slowly degrading quality of service will decrease the usage and cost without too much repetitional damage. They can increase advertisement on their respective services, reduce servers capacity leading to higher latencies, cut R&D leaving only maintenance teams.
Atleast where I live, when you fire someone that's it. They're fired. Even if they still work for 60 days because that's the minimum notice period. The only way to reinstitute the contract is if both sides sign a new contract to overwrite the termination. And this can be used to amend the employment contract too.
So where I live, you'd be in a prime position to negotiate better paychecks because without both employee and employer agreeing, a termination has finality.
iiuc the California WARN act doesn't let a large company (more than 15 employees) just fire half the workforce, so I guess these people have been locked out of their work accounts with full pay and informed of a future termination date.
