prirun
They are only doing this now IMO so that they can be the ones writing the regulations to keep us all "safe", just like we need identity verification to "save the children". They want to keep competition at bay so they can have a $2T IPO, and unregulated, "unsafe", Chinese, open-weight, and local AI threatens that IPO.
Band n53 adds premium midrange spectrum to the premium performance of XCOM RAN. As midband spectrum, it provides a balance of speed and coverage for 5G with download speeds up to 250 Mbps and upload speeds up to 100 Mbps, wider coverage than millimeter-wave frequencies and greater efficiency than lower bands for better throughput. If you run the wireless networks that run the world, the combination of band n53 and XCOM RAN is a marriage made in heaven. Learn more in the Terrestrial Wireless section at www.globalstar.com.
Doesn't that just trade slower inserts for faster deletes?
Fun fact: each system had an IN and an OUT coax port, and the coax cable was about as thick as a thumb. If a system died, a small hardware box short circuited, tying the IN and OUT coaxes together. This kept the ring intact, but it would also make that segment of the network longer and there were strict distance limitations between nodes. If the distance got too big, the entire ring broke. Also, if any coax cable got damaged, that also lead to a ring break. Prime had a special diagnostic program they could use on multiple nodes to try to find ring breaks.
INTEGER ARR1(10), ARR2(5)
EQUIVALENCE (ARR1(6), ARR2)
ARR2(1) = 10
I just asked Gemini "do X's TOS allow anyone to access X via the api?" and it said "No", with a long list of conditions for accessing X via their API.
Nitter should give up and call it a day.
It will be as it always has been: these ideas will further enrich the rich, at the expense of everyone else. We'll have our first quadrillionaire, while the masses are debating whether the minimum wage of $7.25/hr should be bumped up.
Jump hash does allow adding more targets and preserves the property that most request targets stay the same when adding a new target, so if you had 3 targets and add a fourth, ~8% of the requests that would have been sent to targets 1-3 are sent to target 4, evenly chosen from servers 1-3.
My average heart rate on the test was 58, lowest was 21 (for 3 seconds), and highest was 250 (for 6 beats). A few minutes after getting in bed, my heart rate regularly is in the 40s and sometimes low 30s.
I do use Firefox. And I couldn't cancel my account myself: had to request it via email since I couldn't login. They were good about doing it right away and said they issued a refund for the balance.
Internet Archive could buy Storj, probably for not much, keep 1 copy of their archive on the IA custom server setup they have now, keep the other copy on Storj, and free up half of the IA disk space. Storj automagically uploads data to 54 nodes, any 29 of which can reconstruct the original data (54/29 is where the 1.8 expansion factor occurs).
I refuse to pay a company for service and then be required to identify motorcycles and traffic lights every time I sign in. I went a few rounds with Vultr customer service and they said (paraphrasing) "It's not something we can fix, you have to talk to Google about it". Right... Google forced you to put their captcha on your web site.
https://github.com/nim-lang/Nim/blob/devel/lib/pure/collecti...
I didn't know about Nimony and just took a look.
https://github.com/nim-lang/nimony/blob/master/lib/std/table...
OrderedTable is now a synonym for Table, ie, both are ordered. To delete a key, the key is looked up to get an index position x in a Seq, the Seq entries after x are shifted left, the Seq is trimmed of the last element, and then the entire table is rehashed because shifting the Seq invalidates the previous hash codes. The performance is better than Nim OrderedTables because at least an entirely new table isn't created, and it probably works fine for small tables, but it still isn't O(1). The performance would be similar to removing an item from a single-threaded sorted list: most painful to remove the 1st element, least painful to remove the last element, but then you still have to rehash the entire table.
Second this. Their BDFL's personality is not suited for the job IMHO.
Example: Nim's hash table data structures (Python dict, Go map) are called tables. There are several variants of these, including OrderedTable. Deleting a key from an OrderedTable had O(n) performance because Nim built an entirely new OrderedTable, filtering out the key to be deleted. There were a couple of reasons for this:
- the internal list that preserved element order was only forward threaded, making an O(1) delete impossible
- Nim tables allowed the same key to be inserted multiple times, each with different values. I thought this was a bit crazy compared to other languages.
I tried to changed OrderedTable to use a doubly-linked list to allow O(1) deletes, and to get the multiple key feature removed.
What I didn't realize is that Araq, the BDFL, used ordered tables a lot in the Nim compiler, used the multiple value feature, and didn't want to add the memory overhead of a 2nd list to OrderedTable. His main reason was "deletes don't happen too often". At that point it became impossible to convince him that for a hash table to have O(n) delete performance was ridiculous and would be unexpected for anyone using OrderedTable. I gave up, left, and haven't been back.
COBOL code:
PROCESS-DATA.
ADD 1 TO COUNTER.
DISPLAY COUNTER.
IF COUNTER < 10 GO TO PROCESS-DATA.
while (counter < 10) {
counter++;
System.out.println(counter);
}
I wrote COBOL code for a few years at a job when I was a teenager. What makes legacy COBOL code difficult IMO is it can sometimes be very hard to maintain a mental execution state when examining the code, for several reasons:
1. all variables are global, aka, WORKING-STORAGE. You list all the variables used in the program and they are accessible to the entire program.
2. programs are divided into paragraphs. Control normally flows sequentially top to bottom through paragraphs, one executing after another. Except that the PERFORM statement can drastically alter this normal flow control, and you can't tell by looking at a paragraph how it will be executed. To do that, you have to look at all PERFORM statements that mention this paragraph or any paragraph physically before it, because in COBOL you can say PERFORM PARA1 THROUGH PARA27. If PARA13 is physically between PARA1 and PARA27, it's potentially going to get executed.
3. In true legacy COBOL, before structured COBOL was a thing (circa 1985), the main control flow statement in addition to PERFORM was GOTO. Lots of flag setting, and lots of GOTOs. So in the previous example, you can't tell if PARA13 is going to get executed because any prior statement might be a GOTO PARA14, skipping execution of PARA13. But even worse, you are still under the influence of the PERFORM THRU, so after PARA27 is executed, control returns to the statement following the PERFORM THRU, wherever that was. But if you GOTO PARA27, without being under a PERFORM THRU, then PARA27 is executed followed by the next sequential paragraph. Trying to figure this out statically by looking at the program can be very difficult, especially considering PERFORMs that are nested at runtime but may not be anywhere near each other in a code listing.
In rollback mode, only the migration thread can be active because it's a write transaction, but I'm guessing in WAL mode, readers can continue to read during the migration, as with any other write transaction. I don't use WAL mode much because for my application (HashBackup), I don't need db concurrency.
Microsoft would do much better IMO if it focused on reducing problems and increasing their ability to support users rather than adding features and constantly changing the way people have to interact with their computer. A lot of people simply don't care about that crap.
Google says: "at the 100 publicly traded U.S. companies with the lowest median worker pay, this ratio (CEO to worker pay) is much higher, averaging 632 to 1.
Also: "From 1978 to 2024, inflation-adjusted CEO pay grew over 1,094%, while typical worker compensation increased by only 26%"
AI: "I'm sorry, a security guardrail prevents me from performing this operation."