I was a point of two local bbses, my setup was Binkley Term as mailer, GoldEd as editor, plus a third tool, the tosser, whose name I cannot remember now. Everything running on OS/2 Warp.
Markdown is widely used but I agree that it's a mess, there are so many dialects..
A similar but better markup is ASCIIDOC; it's formally defined and comes with a Technology Compatiblity Kit (TCK) that can be used to certify the compliance of an implementation with the spec.
Imagine asking to your favorite LLM the following: "get the document attached to the most recent email from Joe and then upload it into my document management system in a new folder within archive 'Important', make sure to name the folder based the topic of the document following the naming convention already in place for folders in the same archive"
This could be possible for the average user after activating the appropriate "email" and "document management" MCP servers in their chat interface - maybe following an activation process similar to that of Alexa skills.
How could a regular user achieve the same via CLI? Where would the CLI process be running?
This reminds me the old days of Windows 95 when I found a software to burn CDs that had a trial version which was limited to 150MB of data or so. If you tried to create a CD bigger than that it would refuse to burn and it would instead open a popup and tell you that the image exceeded the limit of XYZ blocks allowed by the trial version.
So I first decompressed the executable program (Windows executable were often packed at that time [0]), then I opened a binary editor, looked for that specific number in hexadecimal notation in the binary and changed to something much higher. I was than able to burn CDs without limitation.
It used to be like that, computer had limited resources and desktop environments were light. Then at some point RAM became less and less of an issue, and everything started to get bigger and less efficient.
Coyuld anyone summarize why a desktop Windows/MacOs now needs so much more RAM than in the past? is it the UI animations, color themes, shades etc etc or is it the underlying operating system that has more and more features, services etc etc ?
I believe it's the desktop environment that is greedy, because one can easily run a linux server on a raspberry pi with very limited RAM, but is it really the case?
Is the intention of the author to use the number of years bugs stay "hidden" as a metric of the quality of the kernel codebase or of the performance of the maintainers? I am asking because at some point the articles says "We're getting faster".
IMHO a fact that a bug hides for years can also be indication that such bug had low severity/low priority and therefore that the overall quality is very good. Unless the time represents how long it takes to reproduce and resolve a known bug, but in such case I would not say that "bug hides" in the kernel.
How about switching from VS Code to VS Codium? Same experience without the microsoft telemetry. I suppose Copilot won't be included due to licensing constraints.
I am more interested in how MCP can change human interaction with software.
Practical example: there exists an MCP server for Jira.
Connect that MCP server to e.g. Claude and then you can write prompts like this:
"Produce a release notes document for project XYZ based on the Epics associated to version 1.2.3"
or
"Export to CSV all tickets with worklog related to project XYZ and version 1.2.3. Make sure the CSV includes these columns ....."
Especially the second example totally removes the need for the CSV export functionality in Jira. Now imagine a scenario in which your favourite AI is connected via MCP to different services. You can mix and match information from all of them.
Alibaba for example is making MCP servers for all of its user-facing services (alibaba mail, cloud drive, etc etc)
A chat UI powered by the appropriate MCP servers can provide a lot of value to regular end users and make it possible for people to use their own data easily in ways that earlier would require dedicated software solutions (exports, reports). People could use software for use cases that the original authors didn't even imagine.
I think the design is bad: my girlfriend would never wear it. Maybe they know already and that's why the webpage contains only picture of male hands.
Given the many smartwatches on the market which can do so much more, are lightweight and some of them with acceptable battery life (Garmin, Suunto, Amazfit), a smartring is of very little interest to me. But I often struggle to understand why certain products fascinate people, so I may be totally wrong and I wish the makers best of luck.
I agree, that is what I meant: there were people who installed Contrib to have <if> element, but in reality you did not need that you could just use Ant's built-in features like you said. In my opinion installing Contrib to use <if> was a demonstration of not having understood how Ant works.
Here is an American example, Fox suspensions. Fox is one of the main producers of bicycle suspensions. Great products, but check their service intervals for a fork [0], 125 hours.
Now if you practice mountainbike you may ride your bike 1 to 5 times a week. Let's say you only ride once a week for 4 hours: 125 / 4 = 31, you would need to service your fork every 31 weeks. Add some few more rides and you have to service the fork twice a year.
Each service easily costs $150 if done by a bike shop. If you do it yourself (plenty of tutorials on youtube), you need expensive special tools, oil, special grease and spare o-rings and seals easily costs 30-40$ for every service. And you have to properly dispose the old oil.
Ant did not include IF THEN ELSE, unless you added the contrib package.
If you understood the paradigm, you could write branches in Ant files simply using properties and guards on properties ("unless"). Using IF in Ant was basically admission of not having understood Ant.
This said, I used Ant for a very limited amount of time.
I passed the PDF to Claude and asked it to check if there is any part of the document that states that google deprioritizes good search results in favor of advertisement. Here is the output from Claude:
Yes, the document contains highly significant factual findings by the Court regarding how Google deprioritized organic search results in favor of advertising. The most significant findings: The Court documents that the positioning of Google's AI features (AI Overviews, WebAnswers) on the search results page reduced users' interactions with organic web results - deliberately.
Relevant text:
"Some evidence suggests that placement of features like AI Overviews on the SERP has reduced user interactions with organic web results (i.e., the traditional "10 blue links")."
And:
"Placement of features like AI Overviews on the SERP has reduced user interactions with organic web results where Google's WebAnswers appears on the SERP"
Important note: these are not "admissions" in the sense of Google voluntarily confessing, but rather factual findings by the Court based on evidence presented during the trial - which is legally even more binding.
My elderly father unknowingly installed an application on Android after seeing a deceptive ad. An advertising message disguised as an operating system pop-up convinced him that his Android phone's storage was almost full. When he tapped the pop-up, and followed instructions he installed a fake cleaner app from the Play Store. While the app caused no actual harm, it displayed notifications every other day urging him to clean his phone using the same app. When he opened it, the app — which did nothing except display a fake graph simulating almost full storage — pressured him to purchase the PRO version to perform a deeper cleanup.
In reality, the phone had 24 GB of free space out of 64 GB total. I simply uninstalled the fake cleaner and the annoying notifications disappeared.
How such an app could reach the Play Store is beyond me. I can only imagine how many people that app must have deceived and how much money its creators likely made. I'm fairly certain the advertisement targets older people specifically—those most likely to be tricked.
For better or worse, I'm pretty sure that such an app would never land into the Apple App Store.
While I understand the reasons behind this campaign, I have mixed feelings about it.
As an iPhone user, I find it frustrating that deploying my own app on my own device requires either reinstalling it every 7 days or paying $100 annually. Android doesn't have this limitation, which makes it simpler and more convenient for personal use.
However, when it comes to publishing apps to the store, I take a different view. In my opinion, stricter oversight is beneficial. To draw an analogy: NPM registry has experienced several supply chain attacks because anyone can easily publish a library. The Maven Central registry for Java libraries, by contrast, requires developers to own the DNS domain used as a namespace for their library. This additional requirement, along with a few extra security checks, has been largely effective in preventing—or at least significantly reducing—the supply chain attacks seen in the NPM ecosystem.
Given the growing threat of such attacks, we need to find ways to mitigate them. I hope that Google's new approach is motivated by security concerns rather than purely economic reasons.