having worked in a government agency that ditched IBM, let me offer a view of what that looks like from the customer side:
IBM bought a company whose product we'd been using for a while, and had a perpetual license for. A few years after the purchase, IBM tried to slip a clause into a support renewal that said we were "voluntarily" agreeing to revoke the perpetual license and move to a yearly per-seat license. Note: this was in a contract with the government, for support, not for the product itself. They then tried to come after us for seat licenses costs. Our lawyers ripped them apart, as you can't add clauses about licensing for software to a services contract, and we immediately tore out the product and never paid IBM another dime.
I tell this story not to be all "cool story, bro", but to point out that IBM does focus on renewal growth, but they're not geniuses...they're just greedy assholes who sometimes push for growth in really stupid ways.
Until passkeys can pass the test of "my non-technical friends and family don't call me for help about them", passkeys aren't ready. Vendors keep making assumptions about how users behave which are not safe assumptions, and that keeps blowing up the interactions of non-technical users. (I'm sure there's an "assumptions developers make about user accounts" blog out there somewhere.)
For example, my family has had to call me for help on the interaction between passkeys on Apple & Amazon multiple times. They have a shared Amazon account, which neither Amazon nor Apple seem to like. The first problem came when they didn't even know they'd been moved to passkeys - there was a popup that one of them didn't understand, they clicked OK to get it to go away, and suddenly the other partner can't log in, and neither of them can figure out how to log into Prime Video on their AppleTV. Another time one of them got "nudged" to add a fingerprint to the account, again freezing out the other person.
Until that nonsense stops happening, Passkeys aren't ready.
It's funny, I started with rPis for the same reason, but I'm about to replace them. I bought 20 rPi 4Bs for my homelab, and I just couldn't get them to do what I needed. I was looking to run a home k8s cluster and the Pis were just not suited to it at all (don't use sd storage for k8s 'cause it'll burn out the card w/writes, booting off usb was unstable even with powered usb hubs, netboot turned into an enormous pain in the neck).
Yeaaaahhhh...NLM is/was a special beast inside NIH.
At the time I was there they had a budget to die for, and Pubmed was in the top 300 websites in the world (both are probably still true). NLM pushed so much traffic because of Pubmed that they had their own internet connection to avoid DoS'ing the commodity desktop traffic of the rest of the NIH.
I'm going to regret this, I bet, but here we go: Many years ago I was the manager of the team inside NIH/CIT that ran both the border firewalls and the DNS servers in question (to be specific, at the time it was NIH/CIT/DNST/NEB/NSS). Obviously, since I'm not there anymore I don't have any special inside information, but given that the DNS servers were responding to TCP and not UDP during the outage, my bet would be a simple firewall screwup, rather than malice.
Stuff happens - maintenances have unintended consequences, people typo stuff, etc. Don't freak out about every event - save your powder for the real outrages (like 18F).
> It was reasonable to expect that most of them didn't have the technical capacity to accomplish that in the available timeframe.
So what? Just because the owner can't respond in a given timeframe does not give a you (or anyone) the right to appropriate other people's property. By your argument at the height of the Covid lockdowns I would be justified in taking your car & loaning it out to people because you weren't using it and didn't "have the technical capacity to accomplish it in the available timeframe."
The fact that it was a license that IA was assigning to themselves rather than a physical object makes no difference whatsoever.
That can have downstream effects, though. When I talked to them about doing it to my more recent Subaru, they told me I'd lose the front speakers and the in-car microphone as well, since all of them went through the same fuse.
The title is a bit misleading. The point of the article isn't that their ethics board resigned - that happened a while ago (right after the Uvalde shooting). The point of this article is that even after the board resignation over taser-carrying drones and a shareholder proposal to stop drone development, Axon bought a drone company anyway.
> the gold standard should be that anything generated by ai is public domain
That's close to what the Copyright office is laying out as their actual policy for AI-generated work: images or text created by AI prompting with no other human interaction are not eligible for copyright [1]. I like the Copyright office's approach, since it's pretty straightforward - did a human do this? If yes, can be copyrighted. If no, cannot. It follows clearly from the monkey selfie thing from a couple years ago, as well.
Unsurprisingly, though, some people have a problem with that idea. The Washington Post ran an op-ed that they put on the front page of the opinion section for a couple days claiming that this ruling was awful, and would destroy everything. [2] Personally, I'm taking the op-ed writer's opinion with a grain of salt, since he seems proud to have written a book praising NFTs, but that's just me.
Interesting. This could be a bracketing error, because I read
> it includes analysis of many older accounts that haven’t sent tweets in the last 90 days and thus, likely don’t fit
> Twitter’s definition of mDAUs (monetizable Daily Active Users)
As implying that they think accounts that haven't tweeted in the past 90 days don't fit Twitter's mDAU definition. Given the placement of the qualifying phrase, I think that's a reasonable parsing of the sentence, but I see your point that they could be trying to imply their set doesn't fit the definition. If so, that sentence is very badly constructed.
As a third party? Probably not. Which is why it's going to be very hard to disprove Twitter's assertion unless Twitter chooses to share their data.
That's part of why I find articles like this frustrating: I don't think they have the data to actually answer they question they're attempting to answer. Knowing that, what's the purpose of the article?
Except the question isn't about the pure number of spam/bot accounts, it's about the ratio of spam/bots to "authentic" users. If you leave out the lurkers, that ratio gets skewed to mistakenly inflate the bot count.
1) They talk about "active" accounts (meaning have tweeted in the last 9 weeks), and do a bunch of filtering against that. That seems like a huge bias - lurkers exist, and in my experience are usually the majority of users...this step removes them or ignores them entirely. Frankly, until recently, my twitter account would have been one of the ones they would have discarded as inactive. This one thing alone makes me question all of the rest of their results.
2) By the same token, the rate or frequency with which a user sends tweets has no relation to whether a user is monetizable. If they're seeing ads, they're monetizable...lurkers are just as monetizable as high-volume posters.
DomainTools (domaintools.com) is hiring for multiple positions. We’re a mid-sized security company whose goal is to make the internet a safer place. Our part of that (enormous) job is knowing everything we can know about the Internet’s DNS (where domains resolve, who registered them, etc), to help security teams investigate malicious sites/pages/etc. The positions we’ve got open are remote, but limited to North America (US and Canada already, could probably figure out Mexico). The positions are:
* Senior Software Engineer - Cloud & DevOps Platform - This position will research, develop and deliver cloud automation using tools like Kubernetes, Terraform, Argo, Vault, and Kafka. This position is basically building the base that the other engineering teams deploy onto, with the goal to make everyone's lives easier and more consistent.
* Full Stack Software Engineer, Integrations - This position will work with our product and engineering teams to integrate our data into other security products (Splunk, for example). It will touch a very diverse cross-section of the tools in the security space, as DomainTools wants to make sure our data is easily usable in a wide variety of places that teams may want to use it in. The position primarily works in python and Javascript, but may use others as needed (or customer/application requires).
* Senior Software Engineer and Software Developer Engineer-2 - These two positions are on the team I've been part of for the past 2 years. They're on the backend team, building systems to collect data about the entire internet (track the state of all domain names on the 'net, take screenshots of all of them, etc). The teams work primarily in python and golang, deploying services to kubernetes.
* Systems Engineer - This position is with our TechOps team, supporting the operation of our on-prem and cloud applications. This position supports production systems using Cassandra, Kafka, ElasticSearch, Linux, etc.
If you have any questions, I’m happy to answer them. If you feel like any of these sound interesting but are a stretch for you, drop me a line at ageeclough ..at.. domaintools.com, I’d love to talk with you.
DomainTools (domaintools.com) is hiring for multiple positions. We’re a mid-sized security company whose goal is to make the internet a safer place. Our part of that (enormous) job is knowing everything we can know about the Internet’s DNS (where domains resolve, who registered them, etc), to help security teams investigate malicious sites/pages/etc. The positions we’ve got open are remote. The positions are:
* Software Engineer - Cloud & DevOps Platform - This position will research, develop and deliver cloud automation using tools like Kubernetes, Terraform, Argo, Vault, and Kafka. This position is basically building the base that the other engineering teams deploy onto, with the goal to make everyone's lives easier and more consistent.
* Integrations Engineer - This position will work with our product and engineering teams to integrate our data into other security products (Splunk, for example). It will touch a very diverse cross-section of the tools in the security space, as DomainTools wants to make sure our data is easily usable in a wide variety of places that teams may want to use it in. The position primarily works in python and Javascript, but may use others as needed (or customer/application requires).
* Senior Software Engineer and Software Developer Engineer-2 - These two positions are on the team I've been part of for the past 2 years. They're on the backend team, building systems to collect data about the entire internet (track the state of all domain names on the 'net, take screenshots of all of them, etc). The teams work primarily in python and golang, deploying services to kubernetes.
* Systems Engineer - This position is with our TechOps team, supporting the operation of our on-prem and cloud applications. This position supports production systems using Cassandra, Kafka, ElasticSearch, Linux, etc.
If you have any questions, I’m happy to answer them. If you feel like any of these sound interesting but are a stretch for you, drop me a line at ageeclough ..at.. domaintools.com, I’d love to talk with you.
DomainTools (domaintools.com) is hiring for multiple positions. We’re a mid-sized security company whose goal is to make the internet a safer place. Our part of that (enormous) job is knowing everything we can know about the Internet’s DNS (where domains resolve, who registered them, etc), to help security teams investigate malicious sites/pages/etc. The positions we’ve got open are remote. The positions are:
* Senior Data Product Manager - This position will serve as the product “owner” for a set of DomainTools’ data products, including our PassiveDNS, Data APIs, and data feeds. This position will be defining and the roadmaps for these products, working with our architecture & research teams to see how this data could be used in the future, and working with customers to understand what the outside world wants from these products.
* Software Engineer - Cloud & DevOps Platform - This position will research, develop and deliver cloud automation using tools like Kubernetes, Terraform, Argo, Vault, and Kafka. This position is basically building the base that the other engineering teams deploy onto, with the goal to make everyone's lives easier and more consistent.
* Integrations Engineer - This position will work with our product and engineering teams to integrate our data into other security products (Splunk, for example). It will touch a very diverse cross-section of the tools in the security space, as DomainTools wants to make sure our data is easily usable in a wide variety of places that teams may want to use it in. The position primarily works in python and Javascript, but may use others as needed (or customer/application requires).
* Senior Software Engineer and Software Developer Engineer-2 - These two positions are on the team I've been part of for the past 2 years. They're on the backend team, building systems to collect data about the entire internet (track the state of all domain names on the 'net, take screenshots of all of them, etc). The teams work primarily in python and golang, deploying services to kubernetes.
* Systems Engineer - This position is with our TechOps team, supporting the operation of our on-prem and cloud applications. This position supports production systems using Cassandra, Kafka, ElasticSearch, Linux, etc.
If you have any questions, I’m happy to answer them. If you feel like any of these sound interesting but are a stretch for you, drop me a line at ageeclough ..at.. domaintools.com, I’d love to talk with you.
To build on that, allow me to offer a real-world example: a General Contractor I worked with set up as his standard contract as a triplicate form, so you'd sign once and you'd keep one of the triplicate copies as your copy of the contract. The trick was that the back of the triplicate form was where he put the penalties for breaking the contract, but the signature section was on the front, so there was no indication that there were more terms on the back. One of his customers got fed up with his misbehavior, and he lost the ensuing court case because the contract was deemed to be misleading (hiding more clauses after the signature).
I'm not sure if this would fall into the same boat, but if the dark patterns get misleading enough, there is a real-world risk that the contract would fall into the same situation: misleading enough that the hidden portions of the contract can't be applied.
One thing I found in running my home lab was that I kept having to burn it to the ground & rebuild it regularly anyway. For example, dist-upgrade never really works: every time I try I just end up wasting a couple days wrestling with it and then giving up and rebuilding the machine from scratch. Even if I just assumed that I'd have to build from scratch every time, differing app and library versions meant that I couldn't count on a new build being a simple, clean install.
So going with the regular "run things as a daemon on a server" model wasn't actually saving me that much time.
Basically I could to do one of two things:
1. keep using purpose-configured machines and spend a bunch of time writing ansible scripts to automatically re-create them when everything goes pear-shaped and then re-write the scripts when a new version changes stuff.
2. container-ize all my tasks, and make everything else vanilla and effectively disposable. I have to spend some initial time to rewrite my stuff in container-speak, but that's a one-time cost.
Presented like that, option 2 looked like a better option. When a machine has a problem or needs to be rebuilt, I build it with the completely vanilla setup (ubuntu lts, conjure-up k8s) and push my k8s jobs and pods up to it. That's 2 hours instead of a day and a half. (Yes, in theory I could docker-ize everything and run docker-swarm, but it's a small step from there to k8s, and conjure-up makes installing k8s fairly straightforward.)
Frankly, I have a family now, and fucking with fiddly settings and library dependencies isn't fun anymore. I'd rather spend that time doing stuff. k8s lets me divorce my hobby work from the infrastructure, and I like that.
If I can piggyback on this, as someone who's learning Rust right now:
One of my first trial programs in any language is a tcptraceroute, since it's a good mix of super-beginner tasks and one slightly advanced thing. I hit a problem in Rust right at the beginning: obviously I need to make a socket, but which crate do I use, "socket" or "socket2"? Socket doesn't build anymore, but it's still available as a crate and I have to include it as a dependency and "cargo build" my project to find out that it doesn't work. To make it more frustrating, the only other example of a Rust traceroute that I found uses socket, not socket2, so it doesn't build anymore, either.
I did figure it out, but it felt like an unnecessary speedbump.
IBM bought a company whose product we'd been using for a while, and had a perpetual license for. A few years after the purchase, IBM tried to slip a clause into a support renewal that said we were "voluntarily" agreeing to revoke the perpetual license and move to a yearly per-seat license. Note: this was in a contract with the government, for support, not for the product itself. They then tried to come after us for seat licenses costs. Our lawyers ripped them apart, as you can't add clauses about licensing for software to a services contract, and we immediately tore out the product and never paid IBM another dime.
I tell this story not to be all "cool story, bro", but to point out that IBM does focus on renewal growth, but they're not geniuses...they're just greedy assholes who sometimes push for growth in really stupid ways.