Pin all you want, if the repo/vendor/maintainer pulls the release then you're not getting access to your dependencies at all.
If anything, this is the reason you use pull-through proxies. Your proxy will hold the version you depend on, regardless of upstream drama. Keep your proxy backed up and you'll be able to use those dependencies until the end of time, or you finally decide to migrate to an alternative.
I'd say the likelihood is about 50% you have a NPM package in your dependencies right now that pulls some binary or whatever from a random S3 bucket during installation.
>Kubernetes isn't always the right tool for the job, with which i agree, especially for smaller teams
I think this is the key point. Kubernetes is great when used correctly, in the right scenario. And I feel that most of the hate comes from situations where it's not suitable. Kubernetes is just one of the many platforms available to run your code. My point extends to more systems, like Ansible, Chef and all the others. TL;DR it's not a tool for developers, it's a tool for operations and systems integrators.
A developer working on an application shouldn't care about the platform being run on, only defining its requirements - think big enterprise system that just consumes data, processes and stores it. The moment an engineer starts thinking "I need X platform" they're not developing the app anymore, they're integrating it too.
The system integrator should be able to take those requirements and match it to the right platform - choose the OS, native package vs container, scalability, fault tolerance etc. But the system integrator doesn't need to care about the long term maintenance of the platform, just how to integrate the application onto the platform. k8s can be considered here for long term support, ease of integration, portability etc.
The systems maintenance are responsible for ensuring the system has the resources to run the application and fix any faults that appear in the infrastructure - this is where k8s shines the most, because I can drain a node, update it and uncordon it without worrying about where I'm going to move the containers running on the node because k8s will do that for me. Gone are the days where we need to plan taking a machine offline for an hour, making sure the right failover procedures are in place, because k8s should be demonstrating that regularly.
Essentially, kubernetes/Ansible/etc. should not be a part of the development process. It doesn't solve problems that an application developer should care about. It's an operations tool, able to monitor and manage deployed applications. The hate occurs when the wrong people are using the tools, or the right people are using the tools incorrectly.
And of course, these kinds of separations of concern can only really happen in larger teams, on larger projects. Dedicating a few people to maintaining a deployment, a different group to continuous integration, and a 3rd group to actually developing the functionality. That's just not possible in every case, and the most hate seems to come from those in-between scenarios where there's too many people to call it a small team, but too few to enable this separation of concern. Meanwhile, the most love seems to come from those that can differentiate between the many hats they need to wear in a small team.
> A developer working on an application shouldn't care about the platform being run on, only defining its requirements - think big enterprise system that just consumes data, processes and stores it. The moment an engineer starts thinking "I need X platform" they're not developing the app anymore, they're integrating it too.
This feels like a statement that begs more discussion because it's an interesting argument, albeit probably a polarizing one as well.
My experience has been the complete opposite to this - when developers also think about how the app will run, the outcomes will be the best.
No system runs in a vacuum or exists separate of its runtime environments, so attempts to decouple those could lead to countless problems and inconsistencies down the road. For example, if you create a Java app that expects configuration to come from XML files, this may cause difficulty with containerization and won't follow the best practices anymore. If you create an app that stores session data in memory instead of Redis, then it won't be horizontally scalable. Same for shared data, like using the file system for something - that will create a lot of problems with multiple instances vs using something like S3.
Even if you don't pick the platform yourself, you should make sure that the app integrates with it smoothly, hence the 12 Factor App principles can help for many of these cases.
> Essentially, kubernetes/Ansible/etc. should not be a part of the development process. It doesn't solve problems that an application developer should care about. It's an operations tool, able to monitor and manage deployed applications. The hate occurs when the wrong people are using the tools, or the right people are using the tools incorrectly.
In my experience, this leads to knowledge silos, problematic communication, not thinking about Ops concerns during development either due to a missing set of skills or just not caring due to a lack of ownership about the outcome, and just generally a slowed down pace of development.
Now, there probably is a lot of benefit in specialization (e.g. Ops specialists that consult across different teams and projects to make everything more consistent), but in my eyes everyone should know a bit of everything and communicate freely.
If you don't do that, developers use ORMs in their apps and create N+1 problems or large amounts of DB calls due to a lack of joins or no consideration for indices because they're not DBAs after all, other times people don't bother with instrumentation in their apps and introduce problems with proxying configuration due to not caring about the ingress will look like etc.
I actually recall seeing an issue at work about an Ops related problem, recommended a few steps to take care of it, whereas the responsible dev simply told me: "That's not in my job description, i just write Java."
Now, not making people learn about an extremely vast array of topics and spend evenings/weekends doing so would also be nice, but then again, that person didn't solve the issue, i did. The end result is what matters, optimizing the road to it is up to the people in control.
That said, "rockstar devs" or "DevOps" specialists (or whatever the current term is) also carry risks in regards to a low bus factor (everything hinging on them in certain orgs, vs spreading the knowledge), so it's all probably pretty situational and scalable to different degrees.
> when developers also think about how the app will run, the outcomes will be the best
Absolutely agree, but that becomes "engineering" in my view. I'm talking specifically about implementing functionality, not long term views and project direction etc.
> Even if you don't pick the platform yourself, you should make sure that the app integrates with it smoothly, hence the 12 Factor App principles can help for many of these cases.
Which is the role of the system integrator - to integrate the app with the platform it's to be run on.
> In my experience, this leads to knowledge silos, problematic communication, not thinking about Ops concerns during development either due to a missing set of skills or just not caring due to a lack of ownership about the outcome, and just generally a slowed down pace of development.
> Now, there probably is a lot of benefit in specialization (e.g. Ops specialists that consult across different teams and projects to make everything more consistent), but in my eyes everyone should know a bit of everything and communicate freely
Absolutely agree. And I hate that this happens, which is why I try to learn about all levels of the tech stack and not just one domain. But I do feel like this is a people problem, not a tech problem or project problem.
If the team cannot communicate effectively, they're never going to produce the best product, regardless of who knows what, budgets, etc. Ultimately, these roles aren't a waterfall structure. Developers shouldn't throw things over the fence to system integrators, and similar to operations.
Instead, the whole team works together, in the same space, on the same backlog. If ops has a problem, it gets prioritised on the backlog. If developers are unsure of how to approach something, they talk to the integration or ops people. In an ideal world, the teams would rotate between roles regularly, so that everybody is aware of the issues being faced that can't be seen from elsewhere.
Based purely on my own experience, far too much priority is put on budget constraints and making money instead of making a product that a customer actually wants. And this often leads to the one person, many hats issue, which then cascades into a mashup of roles and chasing our tails. I've had a lot more success on projects where we've clearly defined who owns which layers of the stack than when the team are just left to fend for themselves.
> That said, "rockstar devs" or "DevOps" specialists (or whatever the current term is) also carry risks in regards to a low bus factor (everything hinging on them in certain orgs, vs spreading the knowledge), so it's all probably pretty situational and scalable to different degrees
Specialists absolutely have their place, but are not a fixed requirement. Just because a project chooses k8s, doesn't mean it needs a k8s guru to own that layer, merely that the project needs some knowledge in that area to assess the scale required and make the call on keeping it small and manageable, or getting a consultant in for a short time to design and upskill the team, or getting a dedicated DevOps person to make the impossible happen.
But again, there's no reason why all of this couldn't happen with a team size of 1, with that 1 person wearing many hats. The important thing in those situations is knowing which hat is which and prioritising appropriately. My suggestion is a high level model that can be morphed to fit the situation, not a fixed framework that everybody must follow until the end of time.
So then you just sideload the messaging app instead of using the official build that complies with the legal system. Just like many crime groups do already - look at the EncroChat phones that gangs were using.
This just isn't enforceable. Yet more laws made by people that don't understand the technology.
With no proof, yes it's a conspiracy theory. As others have stated, there is another app linked in the wiki article about EncroChat which was developed by the FBI, with evidence to back that up.
> "So then you just sideload the messaging app instead of using the official build that complies with the legal system"
That's not how computers work.
The scanning would take place at the lowest possible layer (ie. keyboard input, or kernel-mode input driver, etc), such that the user-mode software itself wouldn't be able to bypass the scan. It could also happen at the hardware layer.
You'll need to bring your own hardware/software to ensure you're not being monitored.
If you had a look at EncroChat at all, you'd see that they were running a custom Android OS with a bunch of their own apps on it.
Yes, we can take it to hardware level, however, that's not what was being discussed. The idea of mandating app developers to use the scanning tech can be trivially circumvented. i.e. Law makers not understanding the technology.
Mandating a hardware implant to achieve the same goals is a better understanding of the technology involved, but that ends badly for everyone. At least with software, a vulnerability can be fixed. In hardware, you're stuck with buying a new device or living with the vulnerability. Not to mention it's an open statement that the law makers want to spy on you.
How is that going to help you? Googles recent android version are also making sure you can't change the default camera app for in app photos. So you'd have to run a bunch of third party apps in conjunction.
It's possible, just really inconvenient. Except for the "few" people running their custom rom android phones.
So roll back to a previous version and start there. Android is open source. No reason a community couldn't fork it, maintain it and do what they want with it.
Jailbreaking is also a thing. Modifying the OS enough to break through vendor imposed restrictions. Why is that implausible for this example?
I'm not saying it's easy. There are certainly limitations due to the secure boot process of Android devices. But what if there was a way to change the root keys? Then it's an open game. Black market for devices with modified keys, unique per device, sign the image loaded on them to ensure the same level of security, and then load whatever you want.
This idea that our corporate overlords define what we are able to do is the only thing stopping us from proving otherwise. If someone says something is impossible, you ask for proof, question them, check their work. You don't accept and move on. This is a foundation of security research - any business claiming their product is "hack proof" is just asking to be hacked. Same goes here - if the vendor says you're not allowed to do something, you find a way around it.
So what should they do? Copy OP and publish as is with no follow up, investigation or additional information? or should they do their job and investigate a claim that could be of interest to the public?
Not like they could get information from OP, and then make a FOIA request of the two departments OP mentioned to identify similar reports and write the facts up in an article for us to read, understand and decide for ourselves if it's an issue. That's good journalism: give the facts and let the public make opinions, not the current system which gives the opinions and let the public make up the facts. Just like this post, deciding it's a wide spread issue and the comments agreeing it is without any evidence.
Because visual representation is separate from the underlying data structure. A string container doesn't have a specific direction, only a relative one. I.e. This character comes before the next and after the previous. Adding the bidi control code, the string indicates when the visual ordering changes in this relative direction system.
You could absolutely design a new string container that assumes left to right at all times and cannot be changed, but then it's on the programmer to ensure that strings are copied or concatenated in the right direction, at the right location, and substrings searching becomes a minor headache. How would you concatenate an RTL string to a forced LTR string representation? You would have to work out whether the end of the string it LTR or RTL. If LTR, append directly. If RTL find the character where the direction changes and insert the string in there - much more expensive. Better to just append the string, using bidi codes where required, and let the frontend process the string to make the appropriate direction changes. Yes, you may need to search the string for the bidi code to know which direction you're going at the end of the string, but that's just a simple reverse string search for a single control character, and not a complex variable multi-byte search of inferred character directions by codepoint values.
I think the issue is in the locations of which bidi codes are rendered. They provide an inherent untrustworthy-ness to the text area they're rendered in, and so should be treated as an exception in critical situations. I've seen the reversed exe file name trick used for years, and every time I ask myself why that's even a thing? If the OS used file headers and magic numbers to determine file types instead of the filename, it would be less of an issue.
For source code, I would question the rendering of RTL text in a source code editor as it's an obvious issue for code safety. Ideally, all source code would be kept to the same origin language - doesn't have to be english, just consistent. Any non-conforming text should ideally be loaded from a resource rather than inline within the source code, to avoid foreign character contamination and allow easier identification of these issues. Further, source code rendering should only render identified safe control codes, and treat unsafe ones as raw binary values to be shown as such - i.e. \r and \n are safe, \b is unsafe, and bidi codes would also be unsafe. You could even go so far as to include them in the syntax highlighting, but that results in a dependency on syntax highlighting to show the semantics of the source code rather than the text alone.
This is a thing in the UK - both collection and delivery. In fact I can even order in the morning and collect in the evening, if the collection point has the availability on the day. Otherwise I can order for delivery the following day, or up to 2 weeks in advance. Typically a £1 charge on top of groceries, but the actual amount can vary based on how busy the system is in the timeslot you pick - can even be free as a way for them to spread out customers across the timetable.
I didn't use it until the pandemic kicked off, and then I only started using it as a way to avoid the long queues outside supermarkets. And it was a revelation. I can now select everything I want to buy over the course of a few hours to a few days, and then go and collect at the time I picked. I rarely forget anything, as I can just add it to the order as I remember it. And from arrival to departure is normally no more than 10 minutes, can be ridiculously short if you pick the right timeslot, or can be up to 30 minutes if busy - that's still faster than parking, going into the store, wandering around, forgetting things, checking out and loading the car.
The downside to it is if an item isn't available, you may get some weird replacements or just don't get the item at all. But that's not entirely different to if you went inside anyway.
In all seriousness, if Amazon can get a delivery across the country and out for delivery within 6 hours, supermarkets should be able to select your order, pack it and make it available to collect from the store in less time.
Today (Friday) The earliest slot at Ocado (A big established grocery delivery service / Online supermarket with own robot warehouses etc, in the UK) will give me is Sunday morning. I do not know if this is due to cut-off times or slot availability but it is moot.
I'm not worried, I plan these orders weeks in advance (and you can add or remove until the night before).
Other smaller services (e.g. Deliveroo, weezy, gorillas) will come much faster, but they typically just collect and cover the last mile. This seems to be a growth area lately, two of those companies are new.
For me, Morrissons via Amazon is same day most of the time now. Asda has just announced that they launching 1h delivery.
They can do that because, like Tesco, they have supermarkets nearby so it's 'just' a question of getting someone to pick your stuff from the aisles and someone else to drive to you (funnily most Morrissons/Amazon delivery people drive very fancy cars in my area, I have had big Mercedes and BMNWs, maybe private hire taxis filling time).
I don't think Ocado has a dense enough network of local warehouses.
I checked Tesco when posting, and could get a late evening delivery slot on Saturday. Collection I could get 7am Saturday morning. Not saying the system is perfect, but it's definitely possible to get next day delivery on groceries. Even Amazon doesn't guarantee next day on everything after a certain time, and I see this as much the same - you snooze, you gotta wait an few more hours.
I am interested in a deliveroo/just-eat style grocery shopping solution though. If the store can pick and pack your order in 3 hours and put it at the front of the store for collection by a group of drivers that are constantly in rotation, how is that any different from collecting my takeaway and driving it to my house? It really isn't, but it's also not an urgent operation that needs such a quick turn around time IMO. I'm sure others will pay for the convenience, but I'm personally happy waiting 12 hours and collecting it myself so long as I don't have to step inside the store.
> I am interested in a deliveroo/just-eat style grocery shopping solution though
AFAIK, Deliveroo do this already. (1) I've never had cause to try it though.
JustEat might be less inclined to do that as they have traditionally relied more on the individual restaurants' fleet of drivers (e.g. owner's cousin on a moped) rather than running their own fleet.
You're making an apples to oranges comparison. If you knit a scarf and give it away, all you're left with is the knitting needles and the knowledge of how to make another scarf. Same thing with ansible - you're left with ansible and the knowledge of how to write a playbook in future.
But also, why do you care so much about what other people do with their time? Live and let live, my friend. Nobody is forcing you to write ansible playbooks, build your own homelab, or comment on posts you view as a waste of everybody's time.
>> "If software providers develop this technology, they are complicit in a very serious crime and should be required to design their products to stop this happening."
so we should outlaw any piece of technology that can be misused?
This is what happens when technologically inept people make laws to regulate technology. By this standard, cameras should be outlawed in case they're used to take sexually explicit pictures without consent. Computers should be outlawed in case they're used to distribute anything illicit.
Outlawing the production (by any means) and/or distribution (by any means) of non-consensual, sexually explicit material should be enough. If someone can show evidence that someone has produced to shared such content, then that's enough to demonstrate the offence.
No need to go stopping the rest of us from using technology just because some disgusting excuse for a human decided to demonstrate some of the worst of humanity with said technology.
I don't think this applies. Cameras are general tools that have many useful purposes. So are computers.
This is specifically an AI tool that creates fake nudes. Whatever useful, appropriate purposes for this tool (if any) exist - they pale in comparison to your examples.
The quote was about the technology in general, not the specific application.
The technology has plenty of applications in CGI and trying to push through the uncanny valley. By no means am I claiming that a tool designed to generate sexually explicit material without consent is an appropriate use. But the fact is, technology is used and abused every day without having such huge sanctions put on it. What makes this any different? the fact it's new.
But it's not a new trend by any means. 20 years ago, 'x-raying' was a thing. Photoshop someone to look like their clothes are transparent. Or the bubbles effect, using circles cut out of a mask layer to hide clothing to make the image look like a nude without showing anything explicit.
The fact is outlawing technology just means something new will turn up to replace the old. Whereas making the end product illegal to possess and/or distribute gives a far more beneficial power to law enforcement and the legal system. "I'm sorry officer, these were generated using a different tool, so they're actually legal" or "you can't prove what tool was used to create them" would be perfectly viable defences if the tool is outlawed, vs the act itself.
If anything, this is the reason you use pull-through proxies. Your proxy will hold the version you depend on, regardless of upstream drama. Keep your proxy backed up and you'll be able to use those dependencies until the end of time, or you finally decide to migrate to an alternative.