I was looking for a phone. Lots of sellers will list things as brand new which should imply new in box (unopened packaging). After you carefully read the listing, they actually mean open box which is far more variable.
Ebay does not care at all. It makes the search basically useless.
Because what they're scanning for is scrapers. So much linkedin scraping. And I'd bet that the majority of the innocuous-looking extensions are scrapers hidden as other extensions to get users to unknowingly use them.
It doesn't not seem like anything approaching a lucrative business.
TAM: How big is the market for high speed internet that can pay $1200+/year and isn't already well-served by comcast/at&t/etc? And of course, this is all with finite spectrum too. So you can't serve the major cities.
No doubt there exist buyers. But rural Montana doesn't have that many households. Add that 5 year replacement cycle and Musk's Trump alignment that has Europe building their own for security reasons.
These are US telecoms, the satellites blanket the entire Earth at all times. Lower ARPU, but still. Also, it seems like they're swallowing a large percentage of flight/cruise/military internet. And direct-to-cell data coverage of the entire Earth.
There was an instance of a parent taking pictures of an underage child's penis to show a rash to his pediatrician during covid who got his account hard banned.
That said, I bet there's millions of parents with at least one pic of a naked kid.
My bet is it's quasi-random, but if you get "lucky", nothing short of a extremely senior exec can reverse that decision. So probably we need to behave as if these accounts can just get yanked on a moment's notice at random.
I wanted fastmail, but android integration is not great. I wish it integrated with contacts and it simply does not.
I recently had to choose between google workspace for my email and fastmail, I was really going all in on fastmail and then I hit something that really blocked me. I can't remember what it is though
I've been using fastmail for over a decade. davx is fragile. Many phone brands (all the OnePlus for example) interact poorly with it. I regularly have to trigger syncs by hand.
Still better than google, but the story here is not great.
Yeah, many of these comments are extremely misinformed. Oracle has been an application software vendor for a long time.
For example, Oracle sell Opera. Opera manages hotels, both individual and chains. And integrates with their amusement park management software.
People complain about them, but software like that is much closer to an sdk than a finished product. It is generally customized for each buyer for their needs. And the quality of the customization is more on the buyer than on Oracle.
Oracle have a giant suite of these products for POS, guest experiences, amusement parks, hospitality, marketing (b2b and b2c), etc. And companies buy from Oracle because they're not good at making software and because you do leverage some economies of scale.
Probably went with the simplest implementation, if starting from the current “seconds since epoch” value. Let the user do any calculations needed to translate three days into that measurement.
It also efficiently annoys the most people at once: those what want hours will complain if they set it to days, thought that want days will complain if hours are used. By using minutes or seconds you can wind up both segments while not offend those who rightly don't care because they can cope with a little arithmetic :)
Though doing what sleep(1) does would be my preference: default to seconds but allow m/h/d to be added to change that.
Hence the way I would do it (and have for other purposes), as stated in my final sentence. Have the human state the intent and convert to your own internally preferred units as needed.
No no no, see now we just say "computer! do tedious math!", and it will do some slightly different math for us and compliment us on having asked it to do so.
The one true unit of time is hexadecimal encoded nanoseconds since the unix epoch. (I'm only half joking because I actually have authored code that used that before.)
I actually think it is not too bad a design, because seconds are the SI base unit for time. Putting something like "x days" requires additional parsing steps and therefore complexity in the implementation. Either knowing or calculating how many seconds there are in a day can be expected of anyone touching a project or configuration at this level of detail.
Seconds are also unambiguous. Depending on your chosen definition, "X days" may or may not be influenced by leap seconds and DST changes.
I doubt anyone cares about an hour more or less in this context. But if you want multiple implementations to agree talking about seconds on a monotonic timer is a lot simpler
Could you explain what you mean re: ambiguity? I understand why “calendar units” like months are ambiguous, but minutes, hours, days, and weeks all have fixed durations (which is why APIs like Python’s `timedelta` allows them).
The minute between December 31, 2016 23:59 and January 1st 2017 is 61 seconds, not 60 seconds. The hour that contains that minute is 3601 seconds, the day that contains that hour is 43201 seconds, etc. If you assume a fixed duration and simply multiply by 43200, your math will be wrong compared to the rest of the world.
Daylight savings time makes a day take 23 hours or 25 hours. That makes a week take 7254000 seconds or 7261200 seconds. Etc.
That’s what I mean by calendar units. These aren’t issues if you don’t try to apply durations to the “real” calendar.
(This is all in the context of cooldowns, where I’m not convinced the there’s any real ambiguity risk by allowing the user to specify a duration in day or hour units rather than seconds. In that context a day is exactly 24 hours, regardless of what your local savings time rules are.)
"exactly 24 hours" could still be anywhere between 86399 and 86401 seconds, depending on leap seconds. At least if by an hour you mean an interval of 60 minutes, because a minute that contains a leap second will have either 59 or 61 seconds.
You could specify that for the purposes of cooldowns you want "hour" to mean an interval of 3600 seconds. But that you have to specify that should illustrate how ambiguous the concept of an hour is. It's not a useless concept by any means and I far prefer to specify duration in hours and days, but you have to spend a sentence or two on defining which definition of hours and days you are using. Or you don't and just hope nobody cares enough about the exact cooldown duration
If you say "wait 1 day without using a calendar+locale" then the duration is unambiguously 86400s, but if you say "wait 1 day using a calendar+locale" or "wait until this time tomorrow" then the duration is ambiguous until you've incorporated rules like leap/DST. I think GP's point is that "wait 1 day" unambiguously defaults to the former, and you disagree, but perhaps it's a reasonable default.
Yep, this is exactly my point. Durations are abstract spans of "stopwatch time," they don't adhere to local times or anything else we use as humans to make time more useful to us. In that context there's no real ambiguity to using units like hours/days/weeks (but not months, etc.) because they have unambiguous durations.
Leap seconds are their own nightmare. UNIX time ignores them, btw, so that the unix epoch is 86400*number of days since 1/1/1970 + number of seconds since midnight. The behavior at the instance of a leap second is undefined.
In the UK last Sunday was 23 hours long because we switched to BST, and occasionally leap seconds will result in a minute being something other 60 seconds.
No it wasn't. The country instantaneously changed timezones from UTC+0 to UTC+1 (called something else locally), it was no different to any other timezone change from e.g. physically moving into another timezone.
I came here to argue the opposite. Expressing it in seconds takes away questions about time zones and DST.
I think you're incorrect to say that second are also ambiguous. Maybe what you mean is that days are more practical, but that seems very much a personal preference.
I understand the [flawed] reasoning behind "x seconds from now is going to be roughly now() + x on this particular system", but how does defining the cooldown from an external timestamp save you from dealing with DST and other time shenanigans? In the end you are comparing two timestamps and that comparison is erroneous without considering time shenanigans
that kind of complexity is always worth it. Every single time. It's user time that you're saving and it also makes config clearer for readers and cuts out on "too many/little zeroes on accident" errors
It's just library for handling time that 98% of the time your app will be using for something else.
You can sue the old company for that. You had a job that they are not allowing you to do. Courts don't like it when someone isn't allowed to support themselves, and so generally place narrow limits on what a non-compete tan cover. You should sue for the sake of the rest of us who might be next when this tactic is found to work.
Lawsuits take years and are very expensive in time and money. Years of litigation cost Epic billions in legal fees and lost revenue. It's much much worse if you don't start with millions.
And, like news networks, maybe the router companies are forced to let him hire a censor (they like to call them ombudsmen) so the white house can real-time block inconvenient traffic.
spacex is particular is desperately searching for a bagholder. Leveraging the obvious synergies between rockets (a mediocre business), xai (a horrid business), and social media that lost more than half it's already modest revenues...
SpaceX has reasonable business in it. Not a hypergrowth one, but one which should be solid in long term.
To get that to work they just would need to discard Musk and most things with him. Stop trying to make starship a thing, dump everything attached to it. Make a long term plan to improve the core lift capacity with actually achievable improvements.
> To get that to work they just would need to discard Musk and most things with him
I'll have a pet unicorn shitting rainbows before Musk leaves one of his toys or we see in-orbit leading-edge (or anything close to it) processor production. SpaceX is a decent albeit capital intensive business if it's valued at $100-200B. At the proposed $1.5T+ valuation for this dog... the bagholder search is on.
I was looking for a phone. Lots of sellers will list things as brand new which should imply new in box (unopened packaging). After you carefully read the listing, they actually mean open box which is far more variable.
Ebay does not care at all. It makes the search basically useless.
reply