throwaway9870

It is a big handicap building a small company in tech knowing the largest company in the space which does a large number of acquisitions will probably not be interested in you despite how good your work is.

The company is a multi-billion dollar company that absolutely follows all employment laws. They just didn't want to deal with the French laws.

I used to work at a large US tech company known for making a lot of acquisitions. One time I was assisting with one and was having drinks with the VP coordinating a lot of this growth and he explained he would never acquire a French company because of the labor laws. Now, he was a German, so take that with a grain of salt :) However, the key point here is the same story we see repeated all the time: simple things such as labor laws protecting employees can backfire in unexpected ways.

I am not claiming I have the answer or the French laws are wrong, just presenting a data point. Nevertheless, this is HN, so I expect people how dumb I am and how I have no idea what I am talking about. Fire away.

It doesn't have to be a binary check. It could just be another signal that the e-mail receiving system can use to make a determination. Typically, one adds mailing list addresses to an allow list anyways.

The fact that you felt qualified to post about this but don't even know how many people died scares me.

To be fair, didn't the police and govt let protesters take over an entire section of Seattle this summer in which multiple people were killed?

What has happened. Is this really that hard of concept?

I don't think "News" should include criticism. There is a very important place for it along with news, but I think it is important to keep them as separate concepts. Honestly, right now what is presented as mainstream "news" is probably best described as entertainment.

Strong disagree. During the tenure of GW Bush, I saw the mainstream media attack him daily in a way I had never witnessed before. It seemed to transform from debate to contempt and hate.

I learned an important lesson at my first job out of school: high-quality tech people are more common than the person who can effectively lead them. It was a tough lesson for me because I had spent my entire academic career striving to become a top-notch engineer. Don't confuse a leader with a manager. They might be the same, they might not.

This isn't about disk storage, this is about DRAM. A bit flip in DRAM might corrupt data, but could also cause random crashes and system hangs. That generally matters to everyone.

The problem is that with short haul serial links there is a very small operating range where error correction works. Basically the difference between a working link (very low BER) and a link where even ECC is broken (high BER) is quiet small and adding ECC overhead is deemed an overall loss. These links have quite different characteristics from long-haul links that are dominated by ISI. One way to see this is to look at a waterfall plot and note how steep it is on short interconnects. There is a very small range between working fine and completely broken.

NEC commercial displays, absolutely rock solid.

Then we had different experiences. I am not claiming you are wrong and I don't appreciate you trying to discount our experiences.

It is not a single voice in a room of quietness. It is noise from a 1000 directions and you need to pick out that one signal that leads you to success.

I don't think the number of users has as much to do with partitioning a system as the variety of required tasks does.

Depends. I ran into this myself a couple times over the years and dealt with it depending on what changed. What was really nice was the weekly deploy. All commits were fresh in my head so there were not any changes from long ago that I forgot about. That was actually really important. On some holidays we would not do a deploy and even two weeks of changes was a lot more to remember than one week.

So, if I knew the changes well, I could roll back if nothing in the API changed. We didn't like that, but sometimes you just need to be pragmatic. Other times an update was made that forced you to get it working. In this case services helped because rather than the whole system being down, only part of it was. So many of our services were background type work that in most cases, customers would never even know if they were down for even 1-2hrs.

We had good staging environments with a lot of reporting, monitoring and metrics. We never deployed to production code that had not run reliably in staging for a least a couple of days.

> Separate containers for multiple services owned by the same team sounds like a lot of overhead. If I want to work on something do I have to spin up a bunch of containers, with all the overhead that brings? Can I easily use a debugger across all of the code that implements a given feature?

Most of the services just ran normally on a developers system, or we had a docker script that could spin things up locally, or you used one of the development sandboxes running on the system.

BTW, we had a system that allowed very low cost creation and management of containers (VMs in our case). I think that is an important detail.

Could you use a debugger for a feature? Most likely not, because a lot of our features already pulled data from external sources which you had no visibility into.

> You're talking like there was a single "owner" for each service? What did you do when they went on holiday / left? How did people share knowledge about the system?

Same problem every development team has. Who setup up the CI server? Who setup the front-end proxy? Who configured the AWS setup? Everything needs redundancy. We had a list of all tools and services and had multiple names assigned to each one. Even without services a team should have this.

> Dealing with an outside service brings a lot of overhead. It's harder to debug, harder to test. When things are maintained by a separate team it makes sense to treat them as an outside service, but within the same team why would you make all that extra work for yourself?

Because it worked really well and we didn't see that extra work. I disagree that external services are hard to interface to. They are hard to work with when they are buggy, but if they hit the specs, they generally are not an issue. I have no problem interfacing to S3. Because of the loose coupling, things were very extensible and easy to modify. A few times we would replace a service with a new one by adding the new one and slowly migrating everything over to use it. In some cases, that migration took over a year, but that was fine.

> Sounds like you need a better language. I agree that anything that might segfault belongs in a separate service, but most of the time the solution is to not use stuff that might segfault.

LOL, it was Python. Bugs happen, things break. Everything can eventually segfault for all kinds of reasons. Run a complex system for a decade and you will see all types of issues. I remember running OpenVZ before switching to KVM and occasionally we would even see kernel panics.

> How does that fit with "services only had to talk to other services from the same commit"?

You conveniently left out "or branch". Listen, I am not trying to sell anything, I don't care what you think. I am just sharing my teams experience. It was overwhelmingly positive using services to build a complex system with real revenue from Fortune 100 customers for almost a decade.

We had a weekly deploy (plus any hotfixes) that built the images for all the new VMs (we used KVM) and then when done, stopped all the services and restarted them with their new images. Total down time was about 15 sec which for our application was acceptable. The build time was a lot longer than that (3-4 minutes), but that happened before the existing services were stopped so it didn't affect downtime. If any of the services failed to build, the deploy was aborted and the existing services were left running uninterrupted.

The deploy tool was home grown and was part of the repo. Having everything in a mono repo was really important because it dramatically reduced the number of permutations of interfaces that had to be tested down to one.

These trade-offs might not be right for everyone, but for us they were fine and allowed us to create a highly efficient development environment.

We used services to great effect at the company I previously worked at. There was not a single engineer that ever voiced a concern over how things worked. A couple important notes:

* We used a mono repo and services only had to talk to other services from the same commit (or branch). We didn't version service APIs, I think that would have been a huge waste of time for us.

* Our tests did unit tests and integration tests.

* We could use different languages as the problems required. We started one data processing service in Python and migrated it to Go when it became more CPU bound than we were comfortable with. We have an old but extremely reliable C++ service that had been running for almost a decade.

* Each service ran in its own container. When a container/vm would run out of memory, we all didn't have to scramble to figure out who broke something. The person who owned the code for that service dealt with it. If a service started kicking out errors nobody but the owner had to be distracted.

* We had a good team of architects that understood how to build things. We didn't split services across atomic boundaries. We knew how to build interfaces that handled errors robustly. If you don't know how to do these things, you service APIs can quickly become a mess.

* The world is services. Just think about AWS and how it works. There is no such thing as a monolith, eventually you interface to services. Be it a weather API, a CI server, deployment system, a central logger, etc. Just because you didn't write all those services doesn't mean you don't have a service architecture.

* We had really disjoint services that would have made zero sense to put together. For example, the web server that handled the front-end vs a back-end data system that refreshed a product database and built PDF assets based on the data in overnight batch runs. We actually had many of the later for different customers. We had services for central logging, for monitoring, for metric storage, etc. No way would I ever want to push all that into a single service and debug a GC issue or segfault.

* If we had to hotfix a service, we could deploy just that service with zero concern the other services would have an issue.

For us, services were a key part of building a very reliable system that we could update rapidly with minimal risk. We did this for almost a decade. We had a very good group of engineers and never did I hear one of them say services were holding us back. After this experience, I would say everyone one of them is an advocate for the appropriate use services.

Thanks for the info, that stinks for sure. I hope they get it right now that they are revisiting the issue. I have a soft spot for that hospital, my first child was born there.

I can't really get upset until I understand who got it instead of the resident.

I saw this play out 25 yrs ago with workstations. I remember a friend working at SGI telling me that while PC graphics cards were getting better, they would never be as good as the integrated solutions in their workstations.

I have seen Intel from both the technical side and the customer side. From a technical perspective, they are solid, diligent, but slow. They used to do a lot themselves, including IP blocks, simulators, timing tools, etc. I believe they are trying to adopt more modern design flows to keep up with the rest of the industry in terms of costs and schedules.

As a customer, I tried buying compute sticks in large quantities (i.e. 1000s) from a distributor but they would not extend pricing discounts until Intel approved them. In order to get approved, I had to take online training classes and quizes Intel offered. It was insane. No other company I dealt with required anything like that. I spent hours doing online training on their solutions and never was able to arrange a single discount. Finally said screw it and went with a different solution. Hands down the worst company I dealt with.

That makes no sense. You can get torque with lower gearing, therefore, if tractors only needed torque, then even the largest tractors could get by with a tiny engine given enough gearing. The problem is, farmers need tractors to move faster than .1 MPH, so that is why they have large engines that generate serious HP.

Barrier to entry in Ag is the dealerships. Deere has the best US dealership network for heavy equipment outside of CAT. It is Ok if your Tesla is in the shop for a few weeks getting fixed, but for Ag equipment, even a few hours at the wrong time is super painful. Deere has parts for 20yr old equipment and their own freight trucks, don't overlook this advantage.

I don't believe it works in practice. I remember CableCARDs and Tivo, what a disaster that was. Comcast came to my house 3 times and never got the CableCARD to work right, so I gave up and just took their DVR. I imagine an interoperable API would have all sorts of problems, bugs, timeouts, etc. and the company would just claim they are doing what the law requires.

I seem to recall the entire index was on one system and it showed off how fast and powerful a single Alpha system could be. There were still many markets in the early 90s that were highly constrained by chip and system performance.

The guy who coded Alta Vista gave a talk at Stanford that I was able to sit in on. The most interesting story was when a person contacted him and begged him to remove something from the index because his boss was going to see it the next morning. He wrote a filter just to take care of this guy. It was fun stuff back then.

I used QML for a similar application because it would allow me to assemble the OpenGL scene nicely. I used libMPV to render video frames and QML could easily overlay controls and text. You could even render Chromium (QtWebEngine) on the same scene with minimal effort. I know enough to be dangerous, but not enough to dive deep into the stack of technologies, nonetheless, I got a decent app working with no bugs that customers ever ran into.

For my skill level and effort put forth, I don't know what I could have used to would have worked as well.

It is my experience good managers know how to filter through employees to find ones that are manageable. Perhaps not at the time of hiring, but they know how to move people off their teams that they know are not good members. I consider myself a decent manager and built strong teams of people that would still work for me or act as references, but even then, I probably failed with half the people I hired.