Chromecast devices are great devices, which have their position for making dumb, or un-smart tvs pretty smart. I have used them in many different situations and it's very sad to see it go.
They don't have their own remotes; you have to always use your phone. You always have to use the cast feature via your phone; there's no on screen menu for anything.
Support for casting in phone applications to spotty. Your main entertainment source for the Chromecast will be YouTube.
Casting itself, as such, is not suitable as the main TV experience. It's nice as an additional feature, but if you have to use it for every single thing you want to watch, the irksome phone fiddling gets old pretty fast.
You can't install custom applications on the Chromecast, like the Japanese TV app that I use. (Which, by the way absolutely does not support casting from a phone.)
Even an older Android box is much better than just a Chromecast, like a Xiaomi MiBox S, whose built-in Chromecast feature works just as well as a Chromecast.
we implement one for event registration. without queuing, you end up with some hidden complexity around whether a ticket in a cart counts towards the limit or not, and when it goes back into the available pool if that cart doesn't check out in time. none of it is too difficult to implement, but it is difficult to explain to users and creates experiences that frustrate people are or are perceived as unfair. for example, an event can be "sold out" while a payment is processed, and then the event becomes briefly not sold out again if the payment is declined.
a queuing system is easier for people to understand - you get in line, you have three minutes to complete your purchase when it's your turn, and everything that was available when you started your session is available until your session ends. people are still frustrated to have to queue, but at least they can form a mental model for what's happening.
IMHO a lottery system would be a better way to solve this, but event promoters tend to hate that and want a first-come first-served experience. i don't really understand why.
To your last point, I’ve always understood their sentiment to be along the lines of:
- differentially rewarding those customers willing to put in higher levels of effort
- inflating attendees’ sense of the purchase’s value, since they’ve sunk work into acquiring the right to attend/buy
- adding a sense of agency: you “could have” gotten the tickets if you’d just showed up earlier, you have only yourself to blame
- discouraging the sense that the lottery is “rigged” or inundated with scalpers
- for that matter, offering some form of social proof that “other people” (rather than bots) are buying the tickets: taking the amount of time that people take to check out, that sort of thing
- which also offers tangible social proof of the promotion’s desirability: “1,000 people in line around the block” counts for more buzz than “5% chance of being able to spend money on this thing”
- potentially more reliable gauge of the true level of demand, so we can get the right size of venue next time: a lottery rewards trying to game your number of entries, and, depending how it’s constructed, may encourage people to enter on a lark even if they don’t intend to buy
I remember first time writing a web-shop I thought things would be reasonably static. Gradually I changed my mind, it is more like a first person shooter. The new product sticks it's head around the corner and the first one to shoot it gets the kill but it only counts if you make it safely though the transaction in time. Picking customization while the evaporate is like trying to land a head shot.
Hardcore fans demand to feel they earned their spot by having more endurance, being quicker, even if it ends up being kind of luck when it opens up.
I’ve seen something through Ticketmaster that added a lottery system, giving a certain percent of users a shot at tickets a bit before it gets opened up to everyone else. And people with Amex cards or people who demonstrated devotion.
Virtual Queueing / Online Queueing are the terms to find them.
The reason companies use them is for stuff like tickets releasing for an event at time X. People will spam the site and a random number of them will get through which incentivizes people to Sybil whack the site. Much better to provide first-come first-serve with no advantage to late joiners. Of course still not optimal, so some events will offer an initial queue to people who've been before or so on.
I was about to discuss/joke about the possibility of systemd absorbing this project. And hold and behold turns out there is already systemd-boot project competing in this space. I was not aware of that at all.
systemd-boot is actually pretty great. If you're looking for a lean fast (multi-os) uefi bootloader systemd-boot is much easier to set up and less fiddly than grub. I haven't reached for grub in years.
I think there is a fundamental misunderstanding about what a package manager is.
From Wikipedia: "A package manager or package-management system is a collection of software tools that automates the process of installing, upgrading, configuring, and removing computer programs for a computer in a consistent manner." https://en.wikipedia.org/wiki/Package_manager
Helm is a package manager as it consistently,
* Can pull and deploy applications via packages
* Can manage (upgrade/reconfigure/delete) deployed applications
* Can search and find helm charts.
So the difference is it lacks a GUI? Afaik GUI was never a requirement for a package manager.
And another perspective is, as GlassKube does not provide a packaging mechanism, and uses helm in the backend (established in another question, which I'll also reply) it's not really a package manager but a frontend to another one.
(examples: dpkg - package manager - apt-get/apt/aptitude frontend)
Also IMHO, Considering CNCF landscape, Glasskube is more positioned as a Continues Delivery tool than a package manager. But this is my take.
When I check the packages repo, I see that they are yaml.files linking to helm packages. Is this only capable of deploying helm packages? Is there a packaging solution included too?
> We are still using Helm and Manifests under the hood. However, together with the community, we plan to develop an entirely new packaging and bundling format for all cloud-native packages.
Yes at the moment Glasskube packages wrap around Helm charts and manifests. We don't have a dedicated packaging format as of now.
We are actively looking into OCI images and other possibilities to bundle Kubernetes packages, but focus on features like multi namespace dependencies and simplicity at the moment.
How would you like to package Kubernetes packages or what should be avoided from your perspective?
As a power Kubernetes user providing Kubernetes based paas to internal customers, we are not looking for more GUI or, abstractions over helm.
There are already a lot of solutions out there in this area like helmsman/argocd/helmfile/cross plane helm-provider. And we like kubernetes resources + gitops based automations over any other fancy tools.
Most of the time problems around helm is it's string based templating and lack of type safety. That's why timoni looks a more promising solution in this space. It's lack of packages is the limiting factor.
Another interesting approach is kapp-controller and carvel tooling. Packaging helm charts, OCI images, etc as OCI artifacts to use as a combined source is really interesting. We were considering using kapp-kontroller however our current dependence helm, and some architectural concerns caused us to pass on kapp-controller for now.
As to the question of what could be selling points towards a new "Package Manager" would be,
* Timoni like packages that has templating with type safety.
* A large package pool, or
* Abstraction over helm packages that could add type safety, or better yet automatic or at least semi-automatic conversion of helm charts (One can dream ;))
* Full management through kubernetes API / CRDs
* Multicluster management, or fleet management.
The approach is comparing
- Theoretical configuration errors, or theoretical vulnerabilities that may or may not be there with
- Having a new daemon running (a new attack surface) which
- may also have configuration errors, or vulnerabilities as such
- and also removes a few layers of user based authorisation with a single root level
This approach is somehow considered more secure.
And in a rational way, and of course for any rational security perspective this can't be considered more secure, just different.
I am not from US or China, and just trying to understand. Searching for car subsidies US gives out this, https://www.reuters.com/business/autos-transportation/us-off... . Wouldn't those grants and loans make the beneficiaries also in government backed business models?
This grants tends to come with strong rules on what you can and can’t do with the money, it’s hard for them to be used to prop up a company substantially, they are used to nudge an industry in a direction the market may not yet reward.
China’s support is an order of magnitude more and essentially allows their companies to be unprofitable and not worry about.
Similar to how American VCs enabled Uber to unprofitably wipe out many countries taxi industries in a way that those taxi companies couldn’t compete with.
> China’s support is an order of magnitude more and essentially allows their companies to be unprofitable and not worry about.
This is not at all the case in China's EV sector. The EV sector is China is extremely cut-throat. BYD is not living off of government subsidies. It's an extremely competitive company that has invested heavily in R&D and which has reduced costs through vertical integration.
Even with these restrictions, wouldn't it possible for a US company to move own funds/or loans from subsidied operations towards being more innovative? With this in mind, isn't this still a government backed business opportunity. Isn't using this opportunity or not on the company leadership?
Also doesn't this kind of thinking leads to an argument that says US govt does not want it's own companies to compete with Chinese ones with these grants by use of limitations?
And another question would be as USA is more of a private enterprise type of a country why wouldn't these VC's and car companies cooperate for this competition?
reply