bacongobbler

Ehh, screen zoom could be better on 4k monitors. I always find the display scaling to be WAY off by default and have to mess around with xrandr settings in the terminal to change fractional scaling. This (and many other basic setup issues) doesn't make for a great first-hand experience when first starting out with Linux.

https://wiki.archlinux.org/index.php/HiDPI#Fractional_Scalin...

Have you taken a look at some of the Helm 3 proposals? One of the points that talks about this exact use case is the concept of a "library chart", which is a way to define a block of code once and import it into another chart. In your case you could then define a block of code which will spit out a set of kubernetes labels that is shared across all your charts.

https://github.com/kubernetes-helm/community/blob/master/hel...

Your other point about it being difficult to interact with the kubernetes and Tiller APIs in any other language than Go is true, though it isn't necessarily a Helm Thing. This is a Kubernetes Thing. Tiller's going away in Helm 3 so the side effect should be that Helm will be much simpler to extend.

2 weeks is the norm for regular jobs, but top tech companies are really struggling to fill top talent spots these days. While it is perfectly legal to give only 2 weeks notice, it's normally better to ask your manager how much time they'd reasonably need to fill your position, then have a conversation.

So, I'd re-phrase the original conversation as

"Hey Jerry, got a minute? Look, I don't think this is working out. I intend to give you a letter of resignation by the end of the day, but I want to discuss how much time you'd need to reasonably fill my position before I give my notice."

Then again, if you

1. hate your job, or

2. your manager is being unreasonable about how much time they need to fill that position, or

3. don't care about burning your bridges

Then go right ahead and give 2 weeks notice. It's up to you to decide how you want to frame the conversation.

It's the exact same story with Windows and Linux. Many old PCs running Windows XP that cannot handle Windows 7's minimum requirements are being wiped by geeks and are installing Linux Mint, Ubuntu, Xubuntu, or some other distro onto these devices.

As long as Linux, postmarketOS or LineageOS are the "weird apps" geeks install for their friends' devices, I highly doubt they'll ever gain any real exposure outside of tech circles.

I would argue the opposite. As a developer I want to have tools that make my life easier to - you guessed it - develop. Enabling unnecessary secure defaults that either hinder or don't apply to my use case is silly.

There's a reason most users choose Ubuntu over OpenBSD as their workstation. I would put good money on the reason is because it's "secure enough" without getting too heavy handed on production use cases.

However, I do agree that there has to be a balance. Most tooling I write tends to lean more towards the "good user experience" side first, and then document the production use case. Either that or release two separate (but similar) products; one for developers, one for operations teams. Docker's doing that with the Community Edition/Enterprise Edition, but I still think the Community Edition is far too heavy-handed when it comes to things like pulling images from "insecure" registries.

Sure, if you look at it from the closed mindset that nobody improves or can "git gud".

It's been proven time and time again that humans can learn and adapt to achieve their own aspirations. Take one quick look at the special olympics; you'll see a very large group of individuals who have all overcome amazing obstacles to become olympians.

Similarly, highly intelligent people may not have the domain knowledge required to understand how to bootstrap a company. Their knowledge domain may come from a completely different environment or culture which has its own mindset on how to bootstrap a company. Being smart does not necessarily make you more equipped than "dumb" (and highly motivated) people, but it does give you a decent head start.

Sure, I have `make` installed and I'm using cmder, but some things do not translate well in Windows.

https://cognitivewaves.wordpress.com/makefiles-windows/

My only gripe with Makefiles is the lack of support on Windows. I work on several Go projects, all of which use a Makefile. It makes for a great experience on MacOS and Linux, but on Windows I have to break down the Makefile logic into powershell scripts or run raw `go test/build`. Both are fine, but just pointing out the fact that it's not a silver bullet if your project is intended to work across multiple platforms (like a CLI).

Most put it under ~/go. It's quick and easy.

This is a question you should ask in #helm-users in kubernetes.slack.com. Lots of Helm users are more than happy to help answer questions like this. :)

Because of the per-minute billing nature of Car2Go (as opposed to Avis which is per-hour billing) as well as the convenience of these cars being within walking distance at any point and can be left anywhere within the service area, it is a direct competitor to one-way travel services like taxis. If I'm choosing to use Car2Go instead of a taxi service to drive my fiancé and I to the ferry on a weekly basis or to drive us home from downtown Vancouver after shopping, or I'm driving myself to the airport, then it's a direct competitor with taxis. Keep in mind that in all these use cases, Car2Go and other car sharing services are significantly cheaper than equivalent taxi rides.

There are enough cars in Vancouver that you'll find one within a few blocks 90% of the time, so the argument of "not bringing a car with a driver" is moot unless you don't know how to drive. There's also no surge pricing. It's always the same flat rate.

Cities where ride sharing services like Uber was banned (e.g. Vancouver) have been getting along just fine with car sharing services like Car2Go[1], Evo[2], ZipCar[3] and Modo[4] for years. Uber hasn't really brought anything new to the table asides more competition to taxi companies though more convenient app services and VC money to drive prices lower.

[1]: https://www.car2go.com/CA/en/ [2]: https://evo.ca [3]: http://www.zipcar.ca/vancouver [4]: http://modo.coop

Off the top of my head, this could be used for backups, database migrations, auditing software, report generations, email blasts, CPU/memory intensive operations... The possibilities are endless because the execution layer is just a container, so you're not limited on what exactly is being run inside it.

Yes, the billing is specifically targeted around per-second execution. The containers can start within a few seconds, they allow for customization of CPU cores and memory, and they allow you to focus entirely on your container without having to worry about any VM management. Traditional VM-based infrastructure is still the way to go for long-running applications. This just opens a new avenue into using containers in the cloud.

The value-add here is not to be running cloud instances in containers. Rather it allows you to run containers and be billed by the second, which opens the doors to short-lived jobs running in containers on the cloud. It's closer to serverless platforms rather than VMs.

sarcasm is one of the true idiosyncrasies of humanity that differentiates us from the machines. Embrace it.

poor ruby devs and their two-space indentation rules.

I once owned an FR-S (totaled from someone rear-ending it on the highway, going to buy another next year) and currently I own a '90 Miata and a '94 Skyline GT-R. Comparing between the ND Miata and the BRZ I would go for the BRZ in a heartbeat.

Two reasons:

1. The NC/ND Miata crowd is a much older demographic, keeping their precious car in the garage over the winter, keeping it bone stock, bringing it to the dealership instead of working on it themselves and only taking it out on sunny days. I don't click with that crowd.

2. The aftermarket support for the FR-S/BRZ/GT86 is completely overwhelming. Want a completely different exhaust setup or want to run flex fuel? Turbocharged? Supercharged? There's quite a few choices to select from. ND Miatas have some selection, but not nearly at the same cost or availability.

You can get rid of that torque dip quite easily if it's bothering you, by the way. Just need new UEL exhaust headers and a tune. You'll even make a bit more power when you're finished with it, so win/win.

Personally I'm loving that people aren't buying them because it's been keeping the barrier of entry way down. They truly are remarkable cars... There's a lot more to a car than the numbers. The suspension/geometry and chassis with 55/45 weight distribution, MacPherson struts, Torsen limited slip differential comes standard, and low center of gravity due to its boxer engine are top-notch compared to something like a 370Z.

yes, that's why I pointed it out. :)

I've found low-level web servers (i.e. basic i/o) are really easy to implement in Go. CRUD webapps with an auth layer, database management layer, JSON serialization/deserialization layer etc. are certainly harder to write as you pointed out, but it's possible.

Same thing could be said about the Toyota AE86 in its day. The AE86 came out around the same time when the e30 M3, the mk3 supra, and the FC RX7 were also being released. The AE86 made "only" 128hp, the RX7 turbo made 200hp, and the mk3 supra made 230hp. Guess which one became the icon of drifting in Japan?

Take one look at the grassroots drift scene over at Ebisu Circuit and you'll notice that nearly everyone's running Silvias, Skyline GTSTs and AE86s. Hardly anyone is taking cars with over 300hp to the track... Too much power.

Still happens today on modern social dance floors (read: not the nightclub). You don't want to be stomping your feet on every step unless it's intentional (such as an inflection on a certain part of a song). Otherwise, you're quiet with the feet.

It's actually a lot of fun to be graceful! Quiet with the feet, loud with the dance.

My answer to that question would be "why not"?

So much critical thinking and negativity in these comments for a fun hack... What's wrong with having fun these days?

It's not evil nor is it about the bandwidth costs, it's just business. It's how they get you to spend money on a freemium product after you reach a certain cap. They've determined that you should pay if you're hitting the 10k messages limit.

Support for v1 was dropped earlier this year. v2 is still actively developed and worked on. It's even mentioned in the blog post.

Obligatory disclaimer that I'm an engineer @ Deis working on Workflow daily.

> the old product was End-of-Lifed

To be fair, we did continue to support Deis v1 for 3 whole years(!), which is very long considering we're just a small startup. Being woken at 3AM from yet another obscure etcd/fleet server failure really sucked, and systemd never truly got along well with Docker making for some fun interactions with Fleet. Overall (speaking personally as an engineer and support engineer), we are very happy we made the decision to switch to Kubernetes. Mind you, we were as early adopter as you could get with Fleet and etcd at the time, and etcd in particular has been significantly better for us in terms of stability/error reporting.

> There is no direct upgrade path from v1 to v2

I agree that it sucks there was no upgrade path from v1 to v2, but we felt it was necessary to make breaking changes to move forward from Fleet into the world of Kubernetes. That doesn't change the fact that we never dropped the PaaS product as a whole, though.

> the branding was changed (new product name entirely) to coincide with the release of v2

This was actually more to do with us becoming "Deis the company" more-so than the v2 release. Lots of users were getting confused with "Deis the company" and "Deis the github project", so we decided to rename it Workflow to help make it more clear in conversation.

> and Workflow is a completely separate and different product.

Curious to understand how you feel like v2 is a completely different product. From a user's standpoint the product offering never changed. The API, CLI and `git push` workflows were all still present in v2 and were drop-in replacements, save for backwards-incompatible database migrations (hence v2.0.0). It was just the administration's point of view that changed (Fleet -> Kubernetes, deisctl -> helm). To me it still feels like the same product, but I'm curious to hear from you why you feel differently. :)

Skimming through the comments here so I apologize if you are already aware of this, but please feel free to drop by in #helm on the Kubernetes Slack channel with any questions there. :)

That is true; though technically the Deis v1 PaaS still lives on as Workflow. Internally the v1 PaaS bits are all there in Workflow, just switching out Fleet for Kubernetes. It was just renamed when we became "Deis the company" rather than "Deis the project". I just wanted to clarify that we never "dropped" doing the PaaS thing.

> They've dropped their original PaaS

Just to clarify, we never dropped the original PaaS. Deis (now named Workflow) is still in active development, uses Kubernetes as the underlying scheduler and has monthly releases. We actually just released v2.13.0 5 days ago. :) https://github.com/deis/workflow

> And does this affect dokku by any chance?

No cause effect on dokku. Both are separate projects managed by separate entities.