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

More recent versions of the plan contemplate electrolyzing water in the ground to obtain the required oxygen


Electrolyzing water would also give hydrogen which would make the transpiration of materials easier. I’m guessing that it would require a large amount of electricity to get enough hydrogen/oxygen from the water (they really would need a miniature nuclear reactor).

Edit: for my last comment (which I can’t edit now) I meant to say that hydrogen has a high energy content by mass but not by volume. So 1kg of the stuff has a huge amount of energy but also takes up a lot of physical space.


I’ll take the under


A display mounted on a flat surface between your hands seems like a ready path to neck trauma.


You mean, like a smartphone or a portable console ?


No, much worse, because you are not able to lift it up in front of your eyes while typing.


Why not?


You can't hold it and type at the same time, this device has to be sitting on a surface to type.


How so? You can hold it with both hands and type with your thumbs. Or hold it in one hand and type with the other.


Soylent


Adding significant BOM cost, growing physical volume, reducing battery life, creating lots of complexity to get certain apps to run on one CPU or the other and the associated cache coherency issues? So that iOS developers can test their apps on a native CPU (But still plenty of differences like screen size, no cell radio, no GPS, accelerometers, etc) Seems dubious.


All Macs already have an ARM chip inside them in the form of the T2 chip.


But that’s specifically for Secure Enclave work (disk encryption, biometric data). I don’t think they’d want to risk someone running arbitrary code there and breaking the sandbox. (The SEP is also separate from the A-series chip in the iPhone for a similar reason, IIRC).


In addition to the secure enclave, they already have an A series core on there. That's what runs the touch bar.

There's a full XNU based OS on there called "BridgeOS" that's in the iOS/tvOS/watchOS family.


Open System Information → USB on a Mac with a T2 chip and check out all the stuff attached to it.


So do all AMD Ryzen CPUs in the form of TrustZone/PSP, usually a Cortex-A5. It's equally as user-inaccessible as the T2.


There are probably a dozen ARM chips, e.g. WiFi module, battery controller, touch bar, etc


Also it makes scraping much harder.


All images are still available on the web even delivers everything as JSON. Plenty tools like JDownlaoder can scrap everything in a seconds. they sure have other measurements in place to stop people form doing that large scale.


At the low end it’s worth considering Fargate distinct from EKS. You don’t need to provision a whole cluster (generally 3 machines minimum) and can just run as little as a single Pod.


I tried Fargate and found it to be crappy. It is very hard to use. It is proprietary, so your app will not be portable, and your knowledge and experience will not be portable either. If you use Kubernetes there is tons of tutorials, your app becomes portable across clouds and your knowledge is portable from cloud to cloud too. GKE only costs around $60 per month for a single-machine "cluster".


I use fargate and pretty happy with it. Don't need big scale out - it supports $1M/year revenue so not huge, but LOVE the simplicity.

I just have the CLI commands in my dockerfiles as comments, so once I get things sorted locally using docker I update the task with some copy / paste. I only update occasionally when I need to make some changes (locally do a lot more).

The one thing I'd love to get my DOCKER image sizes down - they seem way too big for what they do but it's just easier to start with full fat images. I tried alpine images and couldn't get stuff to install / compile etc.


You should look into multistage docker builds, that lets you still use a full fat image for your build but then leave all the build tools out of your final image

I liked jpetazzo's post on the subject but there are plenty to choose from https://www.ardanlabs.com/blog/2020/02/docker-images-part1-r...


Someone else suggested the same thing actually. Easy to get lazy when it "just works" and internet is 1gig home and office - you can see how bloat just builds up.


What is proprietary about Fargate? It's containers. I did not find any experience/knowledge (other than the basic knowledge of navigating the AWS console) that wouldn't transfer to any other container service.


AWS console is the crappy part. Azure and Google have much better GUIs. And here's the proprietary part: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/...

For contrast, you can manage a Kubernetes deployment using standardized yaml and kubectl commands, regardless of whether the application is running on localhost (minikube), on Azure or on GKE.

BTW, AWS Lightsail has decent GUI. Alas, it doesn't support containers out of the box. The best support for Docker image-based deployment is Azure App Service.


I'm still not seeing the difference. As pointed out, what you linked is for ECS. That has nothing to do with Kubernetes, so I'm not sure why you're comparing the things on that page to kubectl commands on GKE or Azure. Of course you cannot use kubectl on ECS, because ECS has nothing to do with kube.

When you are using actual EKS (with or without Fargate), you certainly can use standardized kubectl commands.

The only "proprietary" things I see in your link is the specific AWS CLI commands used to set up the cluster before you can use kubectl, but both Azure and GCP require using the Azure CLI and gcloud CLI for cluster deployment, too. There's also setting up AWS-specific security groups and IAM roles, but you have to do those same things on GCP or Azure, too, and both of those have their own "proprietary" ways of setting up networking and security, so I don't see the differentiating factor.


> here's the proprietary part: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/....

That's ECS, not EKS. Two different products.

The EKS documentation is at https://docs.aws.amazon.com/eks/latest/userguide/fargate.htm...

> For contrast, you can manage a Kubernetes deployment using standardized yaml and kubectl commands, regardless of whether the application is running on localhost (minikube), on Azure or on GKE.

Likewise for EKS.


I was replying to this:

> At the low end it’s worth considering Fargate distinct from EKS.


Right, and you linked to the documentation for ECS on Fargate rather than the documentation for Kubernetes Fargate, which is what was being talked about. Again, two different products.


How is Fargate “proprietary”? It runs a Docker containers.

But if you are at any type of scale, the last thing on your to do list is “cloud migration”.


My joke is that the unrealistic thing about Star Trek is not the faster than light travel or the matter transmitters it’s that their videoconferencing always works.


Before we sold, we had WeWork offices in Denver and NY and used a similar competitor in Austin. They worked great and we were happy with them. But they were also a commodity and we chose based on price and lack of lock-in.


Reminds me of Zapata the fish oil company launching zap.com an internet portal and then spinning out and IPOing the subsidiary. [0]

[0] https://mobile.nytimes.com/1999/04/14/business/company-news-...


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

Search: