There is some strange allure for spending time crafting Dockerfiles. IMO it's over glorified - for most situations the juice is not worth the squeeze.
As a process for getting stuff done, a standard buildpack will get you a better result than a manual Dockerfile for all but the most extreme end of advanced users. Even for those users, they are typically advanced in a single domain (e.g. image layering, but not security). While buildpacks are not available for all use cases, when available I can't see a reason to use a manual Dockerfile for prod packaging
For our team of 20+ people, we actively discourage Dockerfiles for production usage. There are just too many things to be an expert on; packers get us a pretty decent (not perfect) result. Once we add the packer to the build toolchain it becomes a single command to get an image that has most security considerations factored in, layer and cache optimization done far better than a human, etc. No need for 20+ people to be trained to be a packaging expert, no need to hire additional build engineers that become a global bottleneck, etc. I also love that our ops team could, if they needed, write their own buildpack to participate in the packaging process and we could slot it in without a huge amount of pain
Wanted to second that Docker Swarm has been an excellent "middle step" for two different teams I've worked on. IMO too many people disregard it right away, not realizing that it is a significant effort for the average dev to learn containerization+k8s at the same time, and it's impossible to do that on a large dev team without drastically slowing your dev cycles for a period.
When migrating from a non-containerized deployment process to a containerized one, there are a lot of new skills the employees have to learn. We've had 40+ employees, all who are basically full of work, and the mandate comes down to containerize, and all of these old school RPM/DEB folks suddenly need to start doing docker. No big deal, right? Except...half the stuff does not dockerize easily requires some slightly-more-than-beginner docker skills. People will struggle and be frustrated. Folks start with running one container manually, and quickly outgrow that to use compose. They almost always eventually use compose to run stuff in prod at some point, which works but eventually that one server is full. This the is the value of swarm - letting people expand to multi-server and get a taste of orchestration, without needing them to install new tools or learn new languages. Swarm adds just one or two small new concepts (stack and service) on top of everything they have already learned. It's a god send to tell a team they can just run swarm init, use their existing yaml files, and add a worker to the cluster. Most folks start to learn about placement constraints, deployment strategies, dynamic infrastructure like reverse proxy or service mesh, etc. After a bit of comfort and growth, a switch to k8s is manageable and the team is excited about learning it instead of overwhelmed. A lot (?all?) of the concepts in swarm are readily present in k8s, so the transition is much simpler
We currently have one foot in Docker swarm (and single node compose), and considering k8s. One thing I'm uncertain of, is the state of shared storage/volumes in swarm - none of the options seem well supported or stable. I'm leaning towards trying nfs based volumes, but it feels like it might be fragile.
Sure. Our solution so far has been both simple and pragmatic - the main DB's do not live inside containers. It's a bit of manual ops, but it works for us. All the 'media' in the stacks I am dealing with is minor enough to serve over a custom API e.g. no massive image/audio/etc datasets where files need to be first class citizens.
We generally avoid mounting volumes at all costs. The challenge of mapping host uid:gid to container uid:gid (and keeping that mapping from breaking) proved painful and not worth the effort
Passion comment: I'll second that most of Jonathan Levin’s books are outstanding, some of my favorite technical guides.
Spent many years as senior dev for a custom Android ROM, yet Levin's book still introduced me to multiple other Android internals I had not yet looked into. Would happily pay 200-300 for his next Android book. Probably not the best books for a total beginner, but if you're already skilled and looking for the next level I would highly recommend.
My only real complaint is that JL seems to do a lot of the marketing/date-setting himself, and it shows. It can be really confusing to keep current on what book he is working on next, what topics will/will not be covered, how to even pay for the book can be a bit complicated (send paypal to this email), etc. It is fantastic that he adjusts and expands book contents as the market/technology changes (e.g. always chasing to get the newest stuff covered in the newest book), but the current end result is a stream of "update" messages on his website that are hard to follow. Would be wonderful if he had someone help him with that "public-facing" side and try to keep things organized/consistent/obvious and hide a bit of "how the sausage is made"
WOuld not be surprised - he's reported piracy issues in past. FYI I've ordered all books by emailing directly to an email on the website. He replies with "send paypal to xx if you want digital only, send xxx if you want me to mail you a hardcopy". clunky relative to an amazon order but it gets the job done
For their objectives, that was undoubtedly a good return on investment. Even ignoring the ROI, the absolute cost seems quite reasonable given the feature set and target market. Someone picked a good CHS or did a good job with avoiding scope creep.
While I applaud them for their understanding and use of technology, it is a strange feeling to see the FBI start to think like the NSA. Given the positive PR of this approach+result other teams will most assuredly try to replicate it
Which is fine, if you ask me. This app was created for criminal dealings, specifically. It was handed over to them by a criminal. They had an op to specifically distribute the compromised app only to the crime networks.
They didn't take over good-faith services. They didn't try to spy on civilians. They didn't try to blanket-surveil the public.
It was a clever, successful and seemingly by-the-books operation.
Not who you replied to, but I believe the current popular answer is to refer to Japan. Numerous articles have been written regarding how they managed their housing crisis by deregulating zoning and building permits. You'll have to read up on it yourself, it's beyond me to summarize as it's a complex topic and the model is not perfectly exportable. Partially for "real" reasons, such as Japan has so many earthquakes that many houses are not intended to last for 100+ years which affects the home economy. Partially for social reasons, e.g. wealthier nations view homes as investments (more-so than as a place to live, like we view an apartment), and people push tons of local/state/federal rules to ensure their investment always grows in value. The easiest way to make the value grow is to ensure there are no more homes e.g. NIMBY
I live in Japan and can tell you that those conditions lead to ugly, low standard buildings that seem to me to be among the very top complaints foreigners living here have about the place. The incentives are completely skewed here and seem just as likely to be corrupt as any other place. There's plenty of discussion about it on these boards, this one comes to mind https://news.ycombinator.com/item?id=26399071
As to the earthquakes/natural disasters bit for why they build relatively disposable homes - does that happen on the west coast of the US, for instance? I'm genuinely interested, if anyone knows.
The low standard one is reasonable as that is what keeps costs low. The alternative is high standard and high cost. You can't really get high standards for low costs.
If the government dictates that all housing needs to be high standard, the collateral damage to that policy is that you can only build housing that prices people out of the market.
> You can't really get high standards for low costs.
I agree but here they're also expensive, which, in my view, is a symptom of the corruption and lack of a free market.
> ugly is subjective so I won't touch on that.
Again I agree, but if you're into industrial estates with lots of concrete and overhead wires galore, then Japan is the place for you. I'm sure someone likes it, maybe the brutalists who made the ugliest parts of my country (the UK) after the war.
Very in favor of modernizing the definition, very not in favor of subsidizing any network buildout -- if a provider is not offering broadband under the new definition that is not (in my eyes) a problem the government needs to step in to fix, it's simply being honest about our nation's network infra capabilities.
Sure, we can incentivize providers for reaching certain percentage rollouts under the new definition, but history shows us we should not consider schemes to help finance those buildouts.
Internet is not currently a utility, so unless we make it a proper utility with proper regulation before handing over money, the federal government is historically not capable of resisting lobbying pressure aimed at remove the teeth from similar subsidized buildout agreements. In almost all cases the money has disappeared without significant real world improvements.
For example, using the money intended for buildout to instead pay lobbyers to re-change the definition of broadband, thereby actualizing some stated goal of "75% of service area covered by broadband", and then pocketing the difference between the actual buildout costs and the lobbying costs.
If we offer a financing without regulation, we may as well move the money straight into the exec bonus category and totally ignore improving infra
Regardless of your opinion on whether it's acceptable, given what is happening in Belarus, that the protestors are working to identify riot police as a way to "fight back"....it's quite interesting (to me at least) that Apple is trying to direct the actions of an app developer after users have already installed that application. Is Apple now the arbitrator of "what computations are allowable on the device you purchased"?
For what it's worth, I have an almost identical experience. Build quality is not good, and every service-center visit leaves you feeling like they are stuffing the service centers with way more issues than the people there can handle. Even with all this, the drive feel of my MS is insane and the screen/app are lightyears ahead. I honestly enjoy driving again, even pre-pandemic with crazy traffic. Their offering is so good it outweighs the crappy support.
If some other car company would step up to the plate and try to complete with similar tech but offering higher reliability, I would go for a test drive immediately.
Side-note: service at Tesla used to be golden. When they first started, they all knew they were pricy cars and everyone expected some growing pains leading to QC issues. It was great - they would loan you a top-model performance tesla while your car was in the shop (great up-sell!!!), they were doing far more of their "mobile service" (super handy, they drive to you and fix the car where you are), and you would get one agent that called you almost daily with an update.
As they have expanded more towards mass market they have gone the way of google - trying to automate humans out of the loop. It's basically a miracle to talk to a human at a service center now, everything is "schedule it in-app where you get 200 characters to explain your issue, we send over an estimate, you can't call to discuss it either approve or don't, drop your car, use our SMS platform for 100% of communications because email might "violate your privacy" (read: leave a data trail), handle the fact that different agents get your SMS at different times and some have no idea what the history is, handle that agents now "have to reply to all messages before they leave" and you're getting hurried "here's my panicked update" messages at 11:30 at night.
I personally feel they missed an opportunity to offer "luxury service lanes" for folks buying the luxury line when they went mass market.
I rented a BMW (not a luxury model, the cheapest automatic available from Sixt in Denmark), and the experience was much better than any car I've driven before. The touch screen worked fine, and having a big map on the center console and a small map on the panel behind the steering wheel was really impressive to me. Adaptive cruise control, lane assist, and proximity warnings made driving much less stressful than it used to be.
But I also have owned a car in 12 years, have only rented 4 cars in that time, and borrowed a parent's car occasionally when visiting them, so I don't really know if BMW's work is really ahead of many others or if they're more standard features you see in all cars.
Personal anecdote: I'm still driving the 2011 BMW 335i that I bought in 2014. It now has 265,000+ miles.
The key with owning a BMW is to do all of the maintenance yourself. That brings the cost of ownership back down to planet Earth.
I've replaced the water pump twice, high pressure fuel pump once, and the radiator. Plus a few odds and ends.
If I had paid the dealer for this work, I'd be totally in the hole.
One thing I will give BMW is that they know how to design a chassis. The car has all of the original suspension components and the steering is still as tight as the day I got it. No clunking, no rattles, no bouncing, etc.
Did BMW learn a lot from the nine production years where their chassis cracked so badly that the wheel supports reliably tore away from the rear subframe? Or the control arms bearings that would disintegrate every 50k? The rear differential bushings and the GUIBO flex disc that both require regular replacement to prevent the car destroying itself?
Not to mention the little stuff, like the window regulators and sunroof self-destructing, the ignition tumbler corroding and disabling the car's internal bus so the lights freaked out, or the headlight mountings disintegrating.
As the owner of an E46 that I purchased used at 100k and now sits defunct at 155k I'm baffled by your comment. I'd fix everything on that car and four unrelated things would break the next month. "Preventive maintenance" wasn't oil changes and brake pads... it consisted of half-replacing major systems at regular intervals.
Maybe they just got their shit together on the newer models, but yeesh.
The E46 is pretty easy to work on, and the subframe thing they fixed for free (after some lengthy lawsuits). I took mine to 200k and never really had any big problems, just the usual stuff (DISA, water pump, oil filter housing leaks, a/c relay, one window regulator). I think the 325 might have had it worse though.
from what i understand they are somewhat notorious for being fickle / needing lots of maintenance. which is certainly the experience my father has had with his, haha. still loves it, though.
Dang, this sounds like taking literally everything I hate about "the future", and doubling down on it. I just had a bad experience with a dealership where I thought my thorough explanation (including error codes) was sufficient to narrow down the issue, but they completely ignored anything I said and did their own thing, which ended up solving exactly nothing. I ended up getting the diagnostic fee waived and have now taken the vehicle to an independent shop, where I can speak 1:1 to the owner and actually have my input listened to and respected.
Speaking of hating the future, the all-digital, gigantic touchscreen interfaces terrify me.
I have a 2011 F150 lariat trim truck, and it is not only swanky on the inside, but isn't phased at all by hauling timber, logs or back woods dirt trails that smaller vehicles get stuck in.
One of my favorite features, though, is that there is NO touchscreen. Every control is a physical button or knob, and I can use any of them from touch and muscle memory alone.
I fully expect the truck to survive another 200k miles or so, but dread the day I have to get something newer.
I regularly haul pipes, skis, boards, furniture, or other long and awkward objects that would destroy a touchscreen, or at least render it unusable for the journey.
It's very hard to destroy screen with protection, and it's super easy to destroy some tiny manual control e.g. anything related to air conditioning, tesla interior is minimalistic, no even air plastic fins, so if you have that stuff inside, model Y or 3 is the best choice for you :)
"Cracked button" really doesn't seem like a realistic issue. And they really don't fall off easily. You're free to have your preferences but the reality is still that most physical buttons are incomparably more durable than a touchscreen, especially a large one, especially if it still happens to be a consumer grade laptop screen. Simplicity has its benefits.
And if/when the buttons crack/fall-off there's a very good chance that you can fix it there and then with a drop of super-glue.
Try that with fancy touchscreen...
I am sympathetic to your point; glasses can be very durable nowadays.
In this scenario, though, I would be most concerned with scratching the screen. That, And replacing a broken knob is surely cheaper than a gigantic touch screen should it be actually damaged.
That was scary to look at. The worrying part is they all look like new cars, many of them with low mileage. This doesn't look safe for anyone on the road.
Same boat. Trading in my fancy Chrysler Pacifica minivan for a Toyota Sequoia with physical AC knobs. Right now I have to wait for a computer to boot up, and then click to accept the terms and conditions. Every. Time.
I got a 2020 Pacifica - I don’t need to use the touchscreen to perform any essential tasks. The AC has physical buttons and a knob. I typically just ignore the screen when I drive and there’s “screen off” physical button.
On a hot day I actually start the car remotely and it automatically starts the AC a few minutes before I get into the car. Mine is a hybrid so I can do this even when it’s in my garage.
This is why I love Subaru. Their new cars have a touch screen, but it's mainly for display and advanced settings. Every important control (audio, lights, climate control, etc.) is analog
Not the 2020 outback. So disappointed as was looking to upgrade to a 2020 but the touchscreen everything made me leave it behind. Got an ascent instead because they had a deal.
Mazda is the only company doing it right these days.
Seconded. Just bought a Mazda 6 and one of the reasons was a sensible, buttons-first infotainment system. There's a knob in the center console that I can use to control everything. Besides that, the seat warmer/cooler, the AC, all the basic stuff is controlled by buttons.
But the kicker is that the infotainment system has a touchscreen, but the touch functionality is _disabled_ if the car is moving, because they think it's a hazard to have a person operate it while driving.
It also takes around 4-5 button taps to do things like turn off the heated seats. In most cars you can do that without having to take your eyes of the road
Yes, agreed 100%. I firmly that believe touch screens in cars are a safety hazard.
I think we're going to collectively realize that putting touch screens on everything is a mistake. It prevents you from being able to use an interface unless it has your attention / you are looking at it.
I agree that anything you are expected to need to adjust while driving should have a physical knob, button, or switch. That doesn't preclude you from having a touch screen to do other things though.
All the screens in cars I've tried have made me want to hammer a screwdriver through them because their software was so terrible.
Except for one: The Tesla screen. I'd still prefer no screen at all, but Tesla seems to hire software engineers who understand that human factors are a thing, and who seem to have an actual degree in computer science.
Seems that these sorts of "policies" & practices strongly contradict Musk's semi-famous directives about crossing company boundaries to get things done, not respecting the chain of command [0,1]
This forces everyone into the same malfunctioning funnel, and it doesn't appear to work for the employees either.
Tons of respect for Musk's accomplishments, but I hope it doesn't go the way of Google which is famous for nonexistent customer support...
[0] "Anyone at Tesla can and should email/talk to anyone else according to what they think is the fastest way to solve a problem for the benefit of the whole company. You can talk to your manager's manager without his permission, you can talk directly to a VP in another dept, you can talk to me, you can talk to anyone without anyone else's permission. Moreover, you should consider yourself obligated to do so until the right thing happens. "
> If some other car company would step up to the plate and try to complete with similar tech but offering higher reliability, I would go for a test drive immediately.
VW's commitment to the electric market with ID3 and ID4 is a big deal, given that the success of their Golf/Touareg platforms. VW/Audi fit and finish are second to none, along with their size and ability to compete at the entry-level price point.
In case it helps, IME many of the smaller shops are looking for folks like yourself offering no nonsense business relationships predicated on skill and professionalism vs "can you sort a list".
I know I am - I've bookmarked your website. I run a small R&D shop specializing in one-of-a-kind projects that typically have very non-standard toolchains. We are good at what we do, but we are not good at frontend work and often need a frontend dev to help us internally market a successful project -- e.g. we can build the best system ever, but if no one can see or feel it, it's always an uphill conversation to explain the value add to someone in the client organization.
Yep, should go for a smaller company, typical SV startup, they will appreciate somebody who can program and not mind the like of social skills. The issue might be location though, you either live in a tech hub or you don't, most people don't.
> This is a fork of the excellent gideonred/dockerdoomd using a slightly modified Doom, forked from https://github.com/gideonred/dockerdoom, which was forked from psdoom.
As a process for getting stuff done, a standard buildpack will get you a better result than a manual Dockerfile for all but the most extreme end of advanced users. Even for those users, they are typically advanced in a single domain (e.g. image layering, but not security). While buildpacks are not available for all use cases, when available I can't see a reason to use a manual Dockerfile for prod packaging
For our team of 20+ people, we actively discourage Dockerfiles for production usage. There are just too many things to be an expert on; packers get us a pretty decent (not perfect) result. Once we add the packer to the build toolchain it becomes a single command to get an image that has most security considerations factored in, layer and cache optimization done far better than a human, etc. No need for 20+ people to be trained to be a packaging expert, no need to hire additional build engineers that become a global bottleneck, etc. I also love that our ops team could, if they needed, write their own buildpack to participate in the packaging process and we could slot it in without a huge amount of pain