So there is no technical limitation of HTML itself compared to XML (doc format)? That HTML would be a just as good replacement for XML (.doc format) if someone tried to make a word processor for it?
The HTML document alternative was a massive technical hack. It was flawed mandate from executives in order to maintain relevance in web-based world. Embedded XML and custom styles were used to implemented the format. Also, the IE team worked closely with Office to support richer text formatting. HTML was not enough. Even then, the format still could not support all the features in the product--features like versioning, simultaneous editing, ole embedding, programmability, etc.
I meant if someone were to create a word processor in 2018, with the least amount of work, shouldn't they use HTML as the format of the document? Assuming no need to backwards compatibility with any other doc formats.
As long as you know how to access the data you store, it is mostly irrelevant what format it is in. Bytes are bytes, but less bytes means smaller files.
I think the issue will be that either your Mac will be unsupported for OSX Mojave or at most in an year or so while your machine physically will still be in good working condition.
Considering the lackluster updates of OSX / MacOS, and the fact that the platform matured years ago, I'm not really concerned that I won't be able to use Mojave.
I think the only issue will be if I need to use XCode, which tends to be bound to the latest OS.
> I think the issue will be that either your Mac will be unsupported
What precedent do you have for believing that to be true? The only time Apple has done that in the past is major platform changes (aka PowerPC and later 32bit CoreDuos). Unless Apple shifts to ARM (which is easily a couple years out at best) or Intel comes out with a 128bit processor (which isn’t even remotely on the roadmap), I’d say you are safe for at least another five years, even if those shifts do happen.
My 2012 Mac Pro (cheese grater) can’t run Mojave since the GPU doesn’t support Metal.
There are aftermarket GPUs available, but it’s becoming an ongoing chore to keep the machine running the latest macOS features (needed new wifi card to support handoff and watch unlock etc).
New wifi, SSD, usb3 etc are relatively cheap. The new GPU is getting more expensive and is now actually blocking keeping up to date with major OS releases.
There is no other Mac I currently want to buy (desktop, my own display). MacMini is too underspecced, MacProvis about to be updated and aside from GPU isn’t really any better than my current MacPro - feels end of life and outdated from day 1, a non-starter for me.
So I’ll probably get a new GPU and hope that buys me another couple of years.
I’m running Mojave on my cheese grater 2011 Mac Pro, but I’m guessing that’s because I already had upgraded the graphics cards and didn’t realize it (also upgraded CPUs, RAM, and a bunch of other stuff too). The cheese grater Mac Pros were one of the best machines Apple ever shipped imho.
I've put in USB3, replaced the spinning disk with SSD, upgraded the WiFi and RAM, but haven't done the CPUs yet (already got dual 6 cores, so aside from a slight clock bump not much point).
My only concern is that the CPUs don't support something that the next major version will require, forcing a move off the MacPro 5,2 platform.
I also did USB3, upgraded wifi, SSD (also turned it into a custom fusion disk), ram bumped to 128gb, upgraded from dual quad 2.4ghz to dual hexacore 3.3ghz, added a nVidia 1080Ti (which I had to power off an extra SATA connector from the 5.25” drive bays) and upgraded the ATI (kept it split brands as the nVidia can be a momentary pain when doing OS upgrades).
Works well, had a bit of trouble getting unlock with watch working, but then all of a sudden started, so not sure what that was about, but been good since then.
I think the idea of dumber phone introduces with it another notion, since the phone is seen more as a utilitarian tool(not for entertainment), then it should not have to be replaced frequently.
With the above concept the entire discussion then hinges on how updatable the phone software is? Because if the phone software is not updatable, even the minimum number of apps needed on the phone will stagnate and you'll have to buy a new phone anyhow.
The single biggest point of failure in the updatability of a phone is the devices drivers for the SOC. Linux fails in this regard because the driver ABI is not stable, so you can't run drivers that the vendor launched with the launch kernel. It is this problem of updatable drivers for SOC components that needs to be solved before any idea of a long lasting utility phone becomes practical.
Because in the space of open source operating systems, we realistically only have Linux Kernel.
With each new release of Linux kernel, the internal kernel interfaces that device drivers use, change. So whatever binary kernel driver the vendor released with kernel version x is not going to run with next kernel version y.
You only have 2 options:
1. Either you get the source of device drivers, which the vendors don't release because they want to protect their hardware IP
2. or the kernel keeps its interfaces stable so that drivers released can be reused again.
Right now, both are not happening and that is the real reason Android phones have a life of at most 2 years.
Basic keyword search is great at recall but precision (top 10) gets worse as the number of documents increases. Given the size of the web, basic keyword search tends to perform poorly in terms of relevance. Common Crawl is large enough to see this problem.
I think what OP and several people in this thread actually want is Google search minus synonyms and the ability to specify advanced syntax like AND and NEAR queries. I believe that would go a long way to satisfying someone who says they just want "keyword search".
You are exactly right, and specific keyword search allows you to weaponize a search engine so Google doesn't let you do it. (they have been victimized in the past for letting people specify things that could pull out social security numbers, for example.
Look into commoncrawl.org which provides a free web index which you can query against. Now that cloud is available, you could in theory download the index and load it into Google's big query or AWS and run your experiments.
This looks like a problem to be solved with something like a google search engine for all internal pages and wiki.
Perhaps we should start machine learning to start auto tagging discussions in Slack with the context they're being done in and then expose a search engine like interface to all of Slack conversations, wikis etc.
