There's plenty of weirdness in Git, but honestly my main complaint is that the interface is awful and the documentation makes Dostoyevski look modern and sleek.
262 karma · joined June 26, 2019
There's plenty of weirdness in Git, but honestly my main complaint is that the interface is awful and the documentation makes Dostoyevski look modern and sleek.
They had an unplanned stockholders meeting where the then-CEO was voted out and Elop was ushered in. He did a lot of good stuff like clean up five layers of middle management, got rid of build-it-five-times mentality as well as bring Nokia up-to-date with a bunch of modern practices.
But then he made a PUBLIC speech about Symbian being dead and that they would have an amazing Windows phone at the end of the year. This caused the Osborne effect (https://en.wikipedia.org/wiki/Osborne_effect) to just eat up Nokia.
Nokia was ahead of the game in a lot of things, like platform security -- let's not forget the first iOS ran everything as root and had no App store, while Nokia was making secure boot and encrypted applications happen.
Nokia was five or ten years ahead of everyone else in technology (you can look at iOS history and tick off boxes when they catch up to Nokia), but they had massive problems in their company culture. Nokia could not have bet on the N9 because they just didn't have that sort of mentality.
"Oh whoops, we accidentally sent you next week's numbers."
Oh my WTF, they plonked the numbers into a quadratic and have so far predicted 5 days of deaths accurately.
I feel a lot of people mentioning individual podcasts in this thread is missing the point -- if the masses see Spotify as the place to find podcasts in, that's where they'll find podcasts in. If ad money moves there, content creators will move there, and draw a lot of people with them.
Of course podcasters aren't going to be locked-in, neither will advertisers or listeners, but there will be a significant lure to just going on Spotify.
What's your first reaction when you want to find a video? You go on YouTube. What's your first reaction when you want to find a solution to a silly problem you're sure a solution exists? You go to Google. What's your first reaction when you want to watch someone stream a computer game? You go to Twitch.
THAT is what Spotify wants here. They want to be the first or at least be in contention to being the first whenever anyone wants to find something audio-related. Music, new albums, and apparently now podcasts. They're already a household name so when a normal person hears that there are good podcasts on Spotify they'll just go "oh huh, that makes sense" and if they get interested they might check one out.
I'd like to say I'll keep an eye out for this but honestly who has the energy? A year from now someone will make a nice graphic showing how many podcasters have transitioned to Spotify and how it's affected the field. I find the clarion call to lawmakers both optimistic and naïve, blocking a merger because Spotify MIGHT cause platform stagnation in 15 years is just never going to happen.
Proving yet again, that given ANYTHING that is efficient engineers will eventually try to improve it.
(2) Having a 'verifier' is how mining pools work already, so it's not adding complexity or anything else.
That said, I didn't read the paper either, but I would say thinking about how to harness the massive resources being used to mine crypto these days is nowhere near a wasted effort. At some point, someone is going to look at all the things that have been proposed and the way some network is set up and it will click.
The basic premise is fine: If you have a simple problem, using simple tools will give you a good result. Here you have text files, you just want to iterate through them and find a result from ONE line that's the same in every file, collate the results. No further analysis required.
Every problem in the world can be solved by a bash one-liner, right!?
There's an interesting dichotomy with bash scripts: One school says any bash script over 100 lines should be rewritten in Python, because it's overcomplex already. Another school says any Python script used daily over 100 lines should be rewritten in bash so there are no delusions about it being easy to maintain.
The original article is from 2013, and doesn't try to do any optimization (I guess, the original article is unavailable at the time of writing of this comment), so it would be an interesting question to see what you could do at the Hadoop end to make the query faster. I would imagine quite a lot.
2741 confirmed 5794 suspected 461 severe 80 deaths
Compare to https://www.bbc.com/news/world-asia-china-51275896 , on 28th:
"The death toll from the new coronavirus now stands at 106, with the number of infections almost doubling in a day to more than 4,500."
Can't see sitrep for 28th yet.
If you see someone doing something wrong, call them out. Like this article does. Otherwise they will simply keep doing it.
If you have a problem with someone not getting called out, call them out. Otherwise you are simply protesting the act of calling out because you're afraid to do so yourself.
To use git you need to know clone, pull, commit, push. For larger projects branch and merge. Those fall into a lot of boxes that say "easy" or "elegant," and I really wouldn't hesitate to recommend git to a lot of projects, big or small, discounting specific needs, but I guess you've got some specific concerns that really don't translate well into simple statements.
I've used mercurial only to get some external requirements or tools going, and never used fossil. Could you elaborate a bit on why git is worse than either of them and why I should consider switching ?
About:config in Firefox has 3930 lines. That would be a very, very, very long walkthrough :) I can see it now, "Okay, to use Firefox, you will now have to click 'next' 4000 times." Thanks.
I don't see it as much about knowledge of the game, more about avoiding mistakes and less pressure that lets you look at a game more in-depth. That, and two people will probably coalesce towards something like honte anyway.
Add to this the player opposing is under pressure because he HEARS the discussion. Can he take advantage of knowing plans? Should he?
I'd say this is a nice learning tool, and honestly, anything that keeps you interested and makes learning and playing a bit more fun is fantastic. I've played 5-in-a-row go, pair go, 3-player go, 1-colour go, 3D go and tried different board sizes like 38x38 or 19x19 infinite (sides 'joined'). I've never run across this variant! Seems fun!
Making guesses about what a 2-player team's strength is is a losing proposition, though.
I'd love to read more about these, even if they're mostly routine. 1200 a year seems like quite a bit! You could call the show "Coroner's corner"
If they wanted a detailed question of what to do AND WHY, they could pay a consultant. A consultant would go over around the same points as duelingjello, but also explain why. As an Internet forum answer, it honestly goes above and beyond.
The answer basically strips into two -- first get rid of any and all 'ball and chain' from the old company, existing customers setups and data. Then put the IP to work, making money.
The answer does skip over the general unasked question of "Can I just sell the code?" to which the answer is generally "no." You'd need an existing enterprise or source that knows the code, wants the code and can use the code, which in the modern age is just not going to happen: Startups come and go and everybody wants to make their own solution. Most engineers I know would look at "existing code" as bloat or a hindrance in general, and would look at it as "a sales team problem." If anything, you'll get peanuts for selling the actual code itself.
Building a new enterprise that has a technical team to handle the code and a sales team to sell the code, potentially with an existing customer base sounds like a much better plan. Does it involve risks? Yes. Does it still answer OP's question of wat do? Absolutely.
>Instead Google wants developers to use the declarativeNetRequest API, which has the browser, not the extension, strip content or resources from a visited web sites. This API, though, has a limit of 30,000 rules that can be created.
>Unfortunately, this change will break popular ad blockers such as uBlock Origin, which rely on the original functionality of the webRequest API and need more rules than are available in the declarativeNetRequest API.
Looking at an old picture of ublock origin block lists: https://www.bleepstatic.com/images/news/u/1100723/uBlockOrig... we can see 150,000 rules. The whole point of a rules list (easylist/easyprivacy) is that they're easy to maintain, since it should be a surprise to no one that adding new ad domains is trivially trivial. EasyList alone is 30,000 rules and it alone is woefully insufficient for a modern-day browser. The declarativeNetRequest only allows for ONE type of filter to work. The static kind, i.e. the old, deprecated, bad, insufficient kind.
Recommended reading: uBlock Origin developer's comments on this change (unanswered by google ofc) https://bugs.chromium.org/p/chromium/issues/detail?id=896897...
So I feel we've come to the spot where there's standards, but then there's convention over (a) decade(s) that just trumps standards. Reminds me of DHCP where I've yet to come across three implementations that agree on certain aspects. Also, is 'supports epub x.y' been a selling point in any reader so far?
I'm looking through the changes and holy hell, this makes me feel like punching an engineer, and I am one! Everything is buried under three or more layers, requiring at least 3 clicks and a bunch of scrolling and usually just refers to what they've changed compared to the PREVIOUS version. While fine for a standard, this is absolutely awful for anyone who doesn't work with epub files daily (which I'm guessing is a very small minority).
If you're interested in changes written for humans, this link is what you're looking for: https://www.w3.org/publishing/epub32/epub-overview.html It doesn't contain motivation for these changes, though, so we'll go with "some engineer thought these would be a good idea"
I guess I'd like to ask the working group:
#1 How widespread would you consider high/recent version support for epubs to be?
#2 How would you sell epub 3.2 support to people developing e-readers or reader applications?
#3 Why isn't the first page filled with "Hey guv, you're an engineer who's interested, here's what epub is and does, and here's a link with all the recent changes along with update motivation information" because looking at this site, I could not find a single thing for convincing manager/C-level types to grant 200 product update hours for this.
"Log in or create a free New York Times account to continue reading in private mode."
I guess Chrome incognito is still detectable. Hard pass.
It doesn't take much thought to figure out why the 20-30% numbers are trumpeted loud and wide: The implications are nasty and visceral and when there's a number like that you feel like there's a point behind it, so you start to wonder. Of course, it's the same as with any fear peddler; if you get an emotional response to a news that seems to touch your life, you can be pretty sure you're being sold snake oil for someone else's benefit.
Why not take the message of this research in a positive manner: Of those who suspect false paternity, less than a third are correct.