1,420 karma · joined August 5, 2016
What I do know is that you need specific EDID support when using a DisplayPort KVM because that switches the computer away on a regular basis. If you have multiple screens and a single screen KVM (fairly common) it will do the re-arrangement that you've experienced. With EDID support it keeps both output alive resulting in no re-arrangement.
EDIT: It seems the correct term may be "EDID emulation".
I've got an older Synology NAS that currently stores my 250GB photo library with a lot of RAWs. While it can run docker I'm not going to attempt to run it there. I'm wondering if a VM on my 10700k is going to be sufficient for great performance, or if handing over the complete machine is going to be necessary. I'm happy adding more NVMe 3.0 drives for storage.
I'm also curious how version upgrades have been for you. I want to get out of the ops business but I feel like I'm going to be dragged in.
"A small team of high-skilled product developers has created and launched mini-startups for the last 5 years. We will build and help to validate your product idea in 30 days."
My personal theory is that this stems from many disjointed experiments where the experimentation is viewed as being more important than anything else. Their mission is to deliver revenue, or some other metric, that isn't visible to users, so perhaps they do achieve their goals.
Using Markdown as the storage format solved the problem because it is consistent and templates can easily be updated to support design updates. The problem is now finding a WYSIWYG editor that supports Markdown. I'm glad there is more going on this space, but StackOverflow helped me a lot with https://editor.stackoverflow.design/.
This is just semantics on your part. Whether it's a company being sold, a division, or only a product, then reasonable companies will consider the data handling in a similar way with multiple gap analyses to mitigate concerns. Context is going to dictate what happens. Lesser companies will not consider this heavily and you can end up with the data being more of the value for the transaction. Whether we like it, or not, we are left to trust that these companies will make efforts to enact good policies and follow them.
What I'd expect to happen here is that Google and Squarespace will familiarize themselves with the posture on both sides and Google will want the standards to at least be maintained to a level which removes liability to them. They are very aware of the scrutiny and a big player here so they can force the acquirer to step up to a certain degree.
I don't know enough about Squarespace's security, or complete business model, but they'll be trying to work out what gaps they may need to fill. Google may have clauses that require that this data can't be co-mingled, or must be handled in specific ways for certain countries. The actual handling and what is communicated can take some time as the teams work out how they deal with any gaps. It's also possible that Google find some gaps on their side and have to resolve them before any transfer could actually happen.
Given the implications of service continuity if domains aren't transferred or operational, I can't imagine that they would ask customers to take some action. It creates a support nightmare with confused customers talking to support and then being unhappy they still took the wrong action when you ask them to approve the transfer.
It's self-evident that acquisitions can happen and that data will be transferred as a result. Most most attention is typically on other aspects of how Google handles data and this seems like an attempt to latch onto that.
I personally feel better about basic data security and processing under Google than I would under a company like Squarespace. I know Google have faced nation state attackers so they've got some security chops. I feel that they'll enforce reasonable contractual requirements on the purchaser, but those won't override Google being a safer bet with the basics.
This is exactly the problem, but people have a hard time grasping this because most people interacting with Python have no understanding of how C code interacts with Python, or don't understand the C module ecosystem. I'm not sure if the Python community has a good accounting of this either because I don't recall seeing much quantitative analysis of how many modules would need to be updated etc.
This would help compare with the Python 2 to 3 conversion efforts. Even then, the site listing (shaming?) popular modules with compatibility made a mid-to-late appearance in the process of killing Python 2. Quantification of module updates is obvious thing to have from the get-go for anyone looking to follow through on removing the GIL, but it's not a fun task.
I suspect there will be some butting of heads for a while before they work things out after seeing how the community reacts. All of this could be handled better with some thoughtful proactive engagement, but that's not really how things operate and there is no one to really enforce it.
The customer service experience at the time was great compared to what you'd typically deal with in the UK. I was the person buying computers for my parents' business, my parents' friends, and some of my friends, all through my parent's business . The reps were probably a little confused because they had repeat orders from the same "customer", but knew they were also dealing with a teenager that had done their research. This yielded some fun conversations and I always felt that they wanted to be competitive with their pricing.
Unfortunately, this all changed towards the end of the 90s as PC manufacturers cut costs, moved to the web, and outsourced.
There is zero chance these customers would let an engineer SSH into a production environment either when they have compliance requirements. Either it'll be some just-in-time access via a jumphost, or production changes need to be scripted separately. I would think about some kind of internal tools API offering. You deploy that onsite and all of these tools work through it. You then start more lock-in. If your current tools just hit internal APIs that exist anyway then your tool is easily replaced.
In my experience, repeat listening is going to depend on the content and style of the podcast. Some will naturally bring you along while others can't generate great output consistently. The pattern I see is guest participation in the great episodes. Guests can't sustain a podcast unless there is a strong pipeline.
A podcast like Accidental Tech Podcast is consistently great for the fanbase, to the point where they'll pay for unedited versions. There have only been a few guests over the years and it's completely sustained by the creators. The Rest is History is completely sustained by the creators, but guests are regularly included. Sometimes I'm disappointed when they have a guest. CoRecursive depends on guests and has much more variability for me.
[1] https://en.wikipedia.org/wiki/City_of_Derry_R.F.C. [2] https://www.newsletter.co.uk/news/mini-ladd-youtube-sensatio...
We had the same and worse problems with "thick clients" that came before the web grew. With the right requirements, team, tools etc., you could sometimes build great apps. This was incredibly difficult and the number of great apps was relatively small. Building with earlier server-side web tech, like PHP, isolated everything on the server and it was easier to iterate well than with the "thick clients" model.
SPA reinvents "thick clients" to some degree and brings back many of the complications. No one should claim you can't build a great SPA, or that they have few advantages, but the probability of achieving success is frequently lower. Frameworks try to mitigate these concerns, but you are still only moving a closing some of the gaps and the probability of failure remains higher. Depending on the app you can move the success metrics, but we often end up fudging on items like performance.
We get to a point where there is current model is fraying and energy builds to replace it with something else. We end up going back to old techniques, but occasionally we learn from what was done before.
I find that it's surprisingly rare for people with 1-2 years of experience to be able to give an accurate overview of the last 10 years of web development. A better understanding of this history can help with avoiding (or targeting) problems old timers have encountered and complain about in comments.
Your experience doesn't match with reality. There are multiple sources available describing the growth in macOS usage. One that's quoted in news reports, but hidden behind a paywall, is an IDC report from 2021[1].
It describes macOS penetration at ~23% in 2020 up 6% from 2019. The is supported by descriptions of the impact on enterprise end-user computing management teams that historically have only supported Windows. You can even look at the growth of Intune, and the breadth of acquisitions by Microsoft, to see that Microsoft is very likely supporting 1000s of mac devices.
An important element of how we got here is mobile. Windows had made huge investments in configuration management while OS X was an oddball. Managing it required a different set of tools. iOS and Android adoption in many enterprises caused an end run around the end-user computing gatekeepers from 2007-2012 with a proliferation in MDM solutions.
This eventually led to standardization of so-called "modern" configuration management API/interfaces/tools. The door was opened to more Mac adoption through Apple Business Manager while admins had already adopted modern management tools that covered Windows and mobile.
This doesn't discount the challenge with some users needing to use legacy Windows software. Once upon a time this was a strong moat. For years, IT have been under pressure to make this work on mobile (where feasible) which has cut down the blockers on macOS or Linux usage.
[1] https://www.idc.com/research/viewtoc.jsp?containerId=US46965...
Working through your own company is a much better arrangement, but harder to get setup. You'll have more control over rates and have the opportunity to get more work.
This all depends on having a relationship with someone with some kind of budgetary control and relationship with procurement. If procurement can get a better deal working directly with your company then it's normally possible to work something out. This is a good reason to build relationships with the "highly political" people that technical-types normally eschew.
I want a tool that will pull saved items on Reddit, favorite posts on HN, etc. in addition to bookmarks posted to pinboard.in to a single place. In many ways, the share functionality in iOS allows me to get all URLs into a single place, but this doesn't help on desktop.
I know this isn't necessarily and easy task, if APIs aren't available. I'd be OK with a client component or browser extension, if it was open source and self-hostable.
I'm not sure the devs stopped caring as much as the powers at be. Software development has become more commoditized than we want to believe. Devs following an agile workflow with every intent of performing multiple rounds of optimization find that the product gets shipped as soon as it approximates the thing that had been conceived originally.
It doesn't look like an immediate failure, so the less that leadership takes from it is frequently that the level of maturity they shipped is safe. The cycle continues and eventually folks lower down succumb to this shipping pattern. The only things that get them to optimize is competition that successfully drive home their win was due to performance. This doesn't always lead to optimizations when you are an incumbent who can still close more feature gaps because those often result in higher sales and revenue.