I checked it out and they conspicuously omit the thickness from the FAQ "dimensions" answer. They also avoid any photos of the product that clearly show the thickness. So, guessing it's pretty thick?
I guess? I don't know the exact thickness either, but I held it up sideways behind my Samsung S10 and it was maybe a millimeter or so thicker, so it's not huge. Like 9mm-1cm. I have never thought much about the thickness of it
I am aware that people don't trust the Chinese. Which brands do you trust?
As another poster mentioned about the ReMarkable, the Boox works just fine offline. I do use mine online, e.g. for reading HN as I prefer the E-Ink screen for text. But as for note-taking, everything I do is offline, including moving the PDF documents to the desktop via ADB.
It's not about their Chineseness. They're notorious, unapologetic GPL violators with a poor track record when it comes to privacy and general integrity (paying for reviews, etc)..
Thank you. The GPL violations are a long-term problem, most agreed, but the lack of a privacy policy is an immediate problem. What frustrates me is that I'm usually not complacent about such matters, but I purchased the device during a period of extreme time pressure so I never got around to checking that. In fact the device was specifically purchased to help me better reduce my cognitive load - which it does.
I just wrote to the company in the Feedback feature of the device, asking about where the privacy policy can be found and giving an example of where the privacy policy is found in my Samsung device.
Thank you for making me aware of the issue. I was vaguely aware that there were GPL concerns with Boox, but I did not realize that there is no stated privacy policy - technical potential for exploitation aside.
I think the accepted remedy is to root the device, then use a root-level firewall to prevent it from phoning home. But Boox can of course snap their fingers and undo that any time, and rooting comes with its own set of security concerns. In any case, you're strongly advised to never enter a password on the device using the on-screen keyboard, and rotate any credentials you may have already entered.
If you aren't willing to eat your own "dog food" because it's "less good", then you are making shitty dog food!
The entire point is that you should strive to be a company that makes dog food so good that you would be happy to eat it as not-a-dog because it's above and beyond the bar!
If you are unwilling to use your own product, fix that
There are better and worse societies in this matter.
I'm glad I live in a society where it is acceptable for a bartender to just bluntly ask "what do you want?" without all the pointless chitchat. Or for me to go to my boss and tell him "there is a problem with X, we should do Y, even if you earlier said Y is bad.".
I agree with your first couple of sentences. But the YouTube bit is dangerous misinformation. You cannot match any credible university education by watching YouTube.
There are many wonderful educational channels on YouTube. Just as in a classroom - you cannot passively absorb material and expect to understand it with any depth. You can absolutely get the same education off YouTube. The only advantage a proper course provides is pre-made structure. But even that is accessible to the motivated learner.
The thesis here seems to be that delimiters provide important context for Claude, and for that putpose we should use XML.
The article even references English's built-in delimiter, the quotation mark, which is reprented as a token for Claude, part of its training data.
So are we sure the lesson isn't simply to leverage delimiters, such as quotation marks, in prompts, period? The article doesn't identify any way in which XML is superior to quotation marks in scenarios requiring the type of disambiguation quotation marks provide.
Rather, the example XML tags shown seem to be serving as a shorthand for notating sections of the prompt ("treat this part of the prompt in this particular way"). That's useful, but seems to be addressing concerns that are separate from those contemplated by the author.
I'm sure Claude can handle any delimiter and pseudo markup you throw at it, but one benefit of XML delimiters over quotation marks is that you repeat the delimiter name at the end, which I'd imagine might help if its contents are long (it certainly helps humans).
the antml: namespace prefix is doing extra work here too -- even if user input contains invoke tags, they won't collide with tool calls because the namespace differs. not just xml for structure but namespaced xml for isolation.
Cannot believe it's efficient. XML is the most verbose and inefficient of communicating anything. The only benefit of XML was to give lifetime work to an army of engineers. The next news will be "Why DTD is so fundamental to Claude".
The point isn't to be efficient. If you train an LLM on code with an example execution trace written in the comments, the LLM gains a better understanding due to the additional context in the data. LLMs don't have a real world model. For them, the token space is the real world. All the information needs to be present in the training data and XML makes it easy because it is verbose and explicit about everything.
When you're tokenizing it does not matter really what you use (how you translate that token to-from a text string), the main thing is the overall number of tokens. XML is particularly amenable to tokenization because it is trivial to represent entire tags as a single token (or a pair of tokens, one for the open tag, one for the close).
It gets a bit muddier with attributes, but you can still capture the core semantics of the tag with a single token. The model will learn that tag's attributes through training on usages of the tag.
How well do we understand the tokenization for Claude? I'd posit that the exact human-representation of this markup is likely irrelevant if it's all being converted into a single token.
I had a lot of success with Claude just by telling it I would throw a relevant snippet in a <tag></tag> pair. That's not even XML, nor has it been really needed in my experience.
Even simple --- separators is usually enough to get good results, it just needs to be reasonably clear which items are distinct from each other.
The GP isn't suggesting to literally use quotes as the delimiter when prompting LLMs. They're pointing out that we humans already use delimiters in our natural language (quotation marks to delimit quotes). They're suggesting that delimiters of any kind may be helpful in the context of LLM prompting, which to me makes intuitive sense. That Claude is using XML is merely a convention.
Only in 2nd-brain mythology, which holds that you'll discover connections between your notes that you didn't realize was there. I think it started as eye candy to confuse prospective users considering Roam Notes. They later did something similar with their "Canvas" feature. So, these are features you get with their lack of coherent vision, rather than basic usability and a safe plugin ecosystem, neither of which Obsidian plans to deliver..
Let me provide a counter argument: with the graph you can browse your notes visually in 2D, instead of just the usual list. You can just take notes as usual, easily add #tags and [[links]] in them, and then when you go to graph view you can see connections between those links and you can color code or filter tags. You get a global graph view of all your vault, and local view of any note. Links and tags are literally the core Obsidian features and the graph view sits on top of that. For me that is a coherent vision and utility.
Sorry, the lack of vision I referred to related to Obsidian's leadership -- unserious D&D kids largely unconcerned with usability, performing security theatrics with sync e2ee while their users data is regularly at risk of mass exfiltration via their insanely dangerous community plugin ecosystem.
The on-screen appearance of the feature you're referring to may be visual and coherent, I'm just pointing out that users frequently cite theoretical or anticipated benefits of this feature, not real ones.
reply