Some companies do use Ansible at an higher usage level, on big infrastructure, and where change iterations happens quickly.
In this context the Ansible model might not scale well : Your deployment time is bound by both the network you're using to contact the nodes you're managing, where you literally feel any round-trip your packets have to make, and by the number of nodes you have to perform actions on (which is somewhat solved by the use of mitogen with Ansible for example).
On top of that, for advanced usage, you're still dependent on the fact that Python is present on the system you're targeting with Ansible, which makes the idea that "ansible does not require anything on the target host" a bit false, although most distributions ships with Python by default.
Peekl is targeted towards organizations that requires good scaling capabilities, and high velocity in changes deployments. Having to actively be deploying in this context, instead of passively deploying, can be challenging.
Peekl is an alternative to Ansible, but would probably not be as good as an alternative for small individuals/companies who don't manage an important fleet, or do not have an high number of changes going through.
So your point is valid, note everyone would find Peekl a good Ansible alternative.
Seems like it's targeted at students. They're probably expecting to sell a bunch of them at the time of "back to school" and they'll increase the price after.
At least for Europe, and more specifically France, laptop use in classrooms in high school, is still not a thing. So that would explain why they don't do it everywhere the same and the huge price difference.
The current issue with battery replacement is mainly the fact that they're glued to the phone. Which make them very dangerous to replace, as newbie might try to pry off the battery with metal tools (and you don't want to know what happens when a lithium battery is pierced.)
The only thing that will change as far as I know is that battery won't be glued anymore. You'll still have to open the phone with screw like you did before.
> The only thing that will change as far as I know is that battery won't be glued anymore.
Nothing like that will change, not with this regulation, which already exempts any waterproof device like a waterproof phone. Per the article:
> The iPhone was already exempt from the removability rule under the original regulation, thanks to its battery cycle life and water resistance rating.
They can still glue the battery in, they just have to do it in a removable way.
If you've ever swapped a battery in a phone you would know that there are special battery adhesive foils for DIY battery swaps that have a tab that lets you pull on the adhesive foil and thereby remove the the battery much more easily.
An alternative to Ansible and Puppet, written in Golang.
It's called Peekl, and the idea behind it was to merge the two things I loved about both Ansible, and Puppet :
- The agent/server model of Puppet;
- The ease of writing Ansible code.
It also make sure to solve the problem that both Ansible and Puppet have in my sense :
- Puppet is a slow, decades old application. It's written in Ruby and run inside of a JVM for the server. Applying a catalog can be very long on complex configuration setup.
- Ansible on the other side works well, but the absence of an agent makes it hard to deploy stuff at scale : You being spending more time running your playbooks, than actually doing stuff.
So if you want to take a look at this alternative, head to the Github repository. Feel free to break it, open issues, and pull requests !
I like your idea. I didn't have the time to fully build mine out but I also was hankering for something with better readability and implementation than SaltStack (server/client similar to Puppet).
Yes the pub/sub model gets way faster than the Ansible push model, especially at scale : When you start having a few hundreds of servers, you'll see that you just spend so much time waiting for the playbook to run.
It's also heavily bound to network connectivity, if your server your reaching has 100ms of latency, every time Ansible does something, you will feel those 100ms.
In the case of Peekl, it's easy : The server will read the content from the local disk (depending on what roles you have, your groups, and also load the variables.) And simply sends the "compiled catalog" to your agent who will go through all of it and performs actions as needed.
Yeah, if you trust that they will never push a backdoor to your client on the request of Swiss law enforcement. It's a web app "fgs".
They also admit to scanning all mail to and from non-Proton accounts "for spam". So what's stopping them from one day adding a small if statement that just writes that data to disk, for specific "interesting" users?
Regarding metadata, I sure hope you have nothing to hide in the below emphasized:
> Account Activity: Due to limitations of the SMTP protocol, we have access to the following email metadata: *sender and recipient email addresses, the IP address incoming messages originated from, attachment name, message subject, and message sent and received times*. We do NOT have access to encrypted message content, but unencrypted messages sent from external providers to your Account, or from Proton Mail to external unencrypted email services, are scanned for spam and viruses to pursue the legitimate interest of protecting the integrity of our Services and users. Such inbound messages are scanned for spam in memory, and then encrypted and written to disk. We do not possess the technical ability to scan the content of the messages after they have been encrypted. We also have access to the following records of Account activity: number of messages sent, amount of storage space used, total number of messages, last login time. User data is never used for advertising purposes.
Please quote where in that document the answer to my question is:
> Is there anything preventing Proton from disclosing the email content or metadata?
Also please link me to the source code of Proton's server-side code, so I can audit their scanning of all incoming and outgoing mail, to verify it's not logging them. What you linked above is just the clients.
I'm working on an alternative solution to Ansible and Puppet, trying to mix the best of both world: The pull-based aspect of Puppet, by having an agent running on nodes, and the simplicity of Ansible, by writing playbooks and roles.
It's called Peekl, and is available on Github. Tho it's still in what I'd called "alpha". Lot of new features to come!
Hi! I found that it was the most easy language to get started with. I looked at other language such as `HCL` (the Terraform language) but I thought that it would be too complex to learn, and to get started with. I really want this project to be easy to work with.
What language did you have in mind that you'd rather use compared to YAML ?
YAML is actually tricky, especially with multiline strings and space handling.
I do find HCL to be simpler. But for things like Ansible, I'd rather have a real programming language, like PyInfra does (which I never got to try yet unfortunately).
Yeah at beginning I really wanted to use HCL.. But their parser and implementing it was actually a little bit more difficult that doing just raw YAML parsing.
It also doesn't help that I'm not that familiar with the language.
Some companies do use Ansible at an higher usage level, on big infrastructure, and where change iterations happens quickly.
In this context the Ansible model might not scale well : Your deployment time is bound by both the network you're using to contact the nodes you're managing, where you literally feel any round-trip your packets have to make, and by the number of nodes you have to perform actions on (which is somewhat solved by the use of mitogen with Ansible for example).
On top of that, for advanced usage, you're still dependent on the fact that Python is present on the system you're targeting with Ansible, which makes the idea that "ansible does not require anything on the target host" a bit false, although most distributions ships with Python by default.
Peekl is targeted towards organizations that requires good scaling capabilities, and high velocity in changes deployments. Having to actively be deploying in this context, instead of passively deploying, can be challenging.
Peekl is an alternative to Ansible, but would probably not be as good as an alternative for small individuals/companies who don't manage an important fleet, or do not have an high number of changes going through.
So your point is valid, note everyone would find Peekl a good Ansible alternative.