The support seems quite good actually. I haven't used it personally, but I use a Huawei Matebook (with Arch) hence looked around for kernel patches and touch support – only thing not working for me is hardware buttons and the fingerprint scanner, but there is a patch for hardware buttons on the SP. Lot's of activity on https://www.reddit.com/r/SurfaceLinux/
Like so many projects on the internet: Lots of big words and ideas, but no content. Show us some actual tech and code and I might throw my money your way. Or better: Release your code under an open license and I might even throw my time your way!
I need the money to develop it fully. If it was usable at this point, I would release it, no doubt. I want something out of the door ASAP, that's why it is focusing on 2D games first. That is feasible but still hard.
This is really not a technology in the traditional sense. The runtime itself is nothing new. The real thing is the UX, that is how programming can be made more efficient to do.
I believe if someone supports this, he/she supports the goal of this project, not the concrete implementation.
I love the idea of it... but the video makes it very hard to see how it works. I believe it's possible to show how this works without it actually working right now. I think you might be focusing too much on making it look good and polished, you need to just make it work, bare bones!
I believe it's possible to show how this works without it actually working right now.
Exactly! A short tutorial using screenshots to explain what stuff means, for example, would go a long way and doesn't actually require anything to be implemented as the screenshots could be mocked up.
From their privacy policy: "We cannot decrypt or otherwise access the content of a message.
We also can not decrypt what physical person actually send or received a message."
Well, that's great to hear, but as always: These are just words on a page, how can I know it's true? Where's your code? Where's your security audit? Who's the team?
I really like the idea, and believe if done right it actually can do some so-called disruption, but I think in this market a real disruption will only come if you manage to decentralize (at least so I don't need to trust your servers to be up for me to get my messages) and open source it, but still cater to the masses.
You're running a freemium business model, a model which works well (some ways even better) also with open source code.
Well we guess, when it comes to small companies that are trying to make their way people are more demanding ? Do you ask WhatsApp and co source code ? We have absolut no interest in user data. Thats why you can use Dikalo without even signing up. The messages never reach our servers in clear and we dont even save users emails in clear. We will have security audits. For sure. We are just getting started. Just give us a try :)
This so much.
The only time i see it making sense to release a full-blown distro is for marketing reasons or making a more unified aesthetic experience like for example Elementary (which certainly has its own issues, but that is another story) or for a very specific purpose like Kali or Tails. There are, however, a jungle of different software and solutions out there so sometimes I appreaciate a "curated" list of de facto software to test. Having to install a whole distro for that, virtually or otherwise, might be the definition of overkill.
As always the problem is in the possibilities: The different systems (both distros and user installs) are so differently configured, that a script most certainly will mess it all up.
The best solution I can see (at least for my use) is to expand the dotfile-approach to encompass applications and more advanced settings too. But I guess it has certain security a related issues?
Even a distro-specific script would do the job in many cases.
Elementary is a good example of where some kind of advanced script/package setup could possibly replicate what the developers have done.
What you mention regarding extending the idea of dotfiles to encompass applications/settings is exactly what I'm hoping will start happening rather than this saturation of distros that don't necessarily bring a lot to the table. As for security issues, yes that's always going to be a concern when you add new packages, but no reason why there couldn't be some improved process in place to let users know when they are straying off the path.
"Your thoughts, whether they’re words or sketches, are instantly synced to reMarkable’s cloud service"
Imagine for a company only five years back to literally say that your thoughts are sent to their server. I welcome any product that understand we need less distractions and less help from so-called AI, but there are many reasons to be cautious about this one (preorder, latency claim and lack of technical details being some of them).
EDIT: After looking a bit more around, their technical claims does seem credible. Their CTO is/was even a developer at KDE, so let's hope they also will support open standards and personal servers. If so then it's literally the device I've always been dreaming of!
the reason we're a bit scant on technical details so far is partly because we have spent most of our technical resources on actually making the device. but we'll try to get out a more technical blog post soon.
another reason is that we can't share too much about what we're working on in case some journalist picks up some wording as promising some feature we can't deliver on. a lot of the stuff we're working on is stuff we don't know if we can deliver in time, in a polished enough form. so what we're talking about is what we have already solved, and which we believe is going to sell the device best to the people we target.
lastly, Certain Companies that have tried to do this for years are really, really interested in how we have solved the latency problem, and we don't want to help them.
EDIT:
> Their CTO is/was even a developer at KDE
is, thank you very much (latest commit was to kio on saturday). even if I don't have as much time for KDE stuff as I used to for obvious reasons.
Great to hear from you guys directly! I guess we (i.e techie internet folks, you included) have been served so many crowd funded promises that it's difficult to believe things that are too good to be true. Although I'm personally a big advocate of keeping stuff open, I do understand that a small company has to have some secrets for themselves.
Now I see you're also a developer at KDE which certainly gives credibility to your statements! But on the same note I truly hope the information from the device will be encrypted on your server, and that an opt-out of this sync will be possible. And if there will be support for Owncloud or the like, you've literally made my dream device!
I truly understand and support that you don't promise stuff that aren't really made yet, and I really hope the privacy concerns will be taken as serious as they are.
> I guess we (i.e techie internet folks, you included) have been served so many crowd funded promises that it's difficult to believe things that are too good to be true.
well, I personally have basically stopped contributing to crowdfunding campaigns, I've been burnt a lot. and this is also why we haven't gone public earlier, even when we've been working on this for years.
> I truly understand and support that you don't promise stuff that aren't really made yet, and I really hope the privacy concerns will be taken as serious as they are.
well, privacy is very important to me personally (I even have a couple of commits in owncloud), and we've been discussing several ways to protect the privacy. but until we know which way we do it we can't promise anything, even just speculating will lead to people assuming and get angry if we go for something else.
I appreciate your approach of avoiding speculation (apart from the mass-production uncertainties) and I've just pre-ordered. I have a couple LCD pen tablets (Samsung Note 10 and Surface Pro 3, apart from a USB Wacom Intuos 3) and a Kobo Aura H₂O, and your device looks like something I'd use often.
Just to give you a little feedback, I don't expect any reply for now:
- if the cloud sync can not be disabled I'll just nuke the packets at the router, but I suspect the option will be there.
- I want the SDK (mentioned as possible in your FAQ), unofficial-void-your-warranty all the way to the moon if you want, to have a programmable scientific calculator (maybe with Computer Algebra System functionality if I find the time) on this device. Having to build a complete firmware image in my laptop (Linux) and flashing it just to install my application is acceptable, simply uploading the file as if it was a PDF is better.
these uncertainties is why we hired Dragon Innovation early on. they're very, very good at this and has a very good track record when it comes to hardware startups (e. g. pebble and makerbot).
Funny you should mention Pebble, a company currently in its death throes. I hope reMarkable survives longer than they do, since I have now pre-ordered from both companies.
> One of the issues I personally want to solve is the lack of a hackable e-paper device.
So which is it? You want to make a hackable (I interpret that to mean free and open source) e-paper device where you let everyone see how you solved the latency problem? OR do you want to make a closed source thing where only you and you alone have this magical device that has the lowest latency E Ink panel by a factor of 2?
it won't take many weeks (or days) from we release the device until our solution is reverse engineered, no matter how much we lock it down. but until then we want to keep as much as possible secret.
as for hackable device; we don't intend to release the magic sauce that makes the latency goes down. what I meant with hackable is that I've wanted an e-paper device which I could run my own code on, without having to look for security holes in the software running on it.
but again; we can't promise anything at this point wrt. hackability; we have limited time and resources, and our focus is on making the device as good as possible. our focus is not on making an open source device, we're not going to release the gerber files. :-)
> we don't intend to release the magic sauce that makes the latency goes down.
Ok.
> what I meant with hackable is that I've wanted an e-paper device which I could run my own code on, without having to look for security holes in the software running on it.
If your software is closed source, then I don't understand how anyone other than you effectively (or practically) would be able to solve or fix any security holes.
> we're not going to release the gerber files
You're setting up a strawman there. I was not asking for your hardware design or even mentioning it in anyway. I was pointing out that you are contradicting yourself when you say your product is hackable to software developers and then 30s later say that there will be "magic sauce" in software that will be closed.
> If your software is closed source, then I don't understand how anyone other than you effectively (or practically) would be able to solve or fix any security holes.
I'm sorry if I wasn't clear. I meant that for pretty much all current e-paper devices you aren't able to get access to run your own code unless you find a security hole that you can exploit to gain access.
And sorry about the strawman, it wasn't intended that way. I think the rest of the comment before that answers your original question.
> I'm sorry if I wasn't clear. I meant that for pretty much all current e-paper devices you aren't able to get access to run your own code unless you find a security hole that you can exploit to gain access.
Ok. That helps clarify things.
But on your website, you do not state that your device will permit flashing "your own code". Your website somewhat implies the opposite, it says:
"
DO YOU PROVIDE THE REMARKABLE WITH A SDK FOR CUSTOM DEVELOPMENT?
The reMarkable will not initially ship with an officially supported SDK. We might however release an unsupported SDK for best developers.
"
Could you clarify what "might" and "best developers" means? In multiple comments, you somewhat imply capabilities and features of the product with terms like "hackable" and "run your own code". Perhaps you could put an explicit statement on your website clarifying your position to match your comments.
I'm not trying to imply anything, but what I personally want and what we can do are two different things. I'm sorry if I've been sloppy in my comments here, the last days have been pretty hectic.
I'm one of the guys working on this. We make money on the product, storing this stuff actually costs us.. So we have no intentions of syncing more than you would want to :)
There's some tech specs on the site (getremarkable.com)
For some of us, not being able to turn off sync makes it a no buy (or for work a cannot buy). I hope it will not be required because this device looks interesting.
I have to concur with the others. Sync to the cloud is pretty much the last feature I would want; that would make this device forbidden by default without IT approval in pretty much any business or other professional environment I can think of. Imagine if a doctor bought one and took notes on your device. Is your cloud storage solution HIPAA compliant?
Save the notes to local storage and let me transfer them to a computer locally.
Also would like to sync to cloud of our choosing. Dropbox, box, one drive, adobe cloud, etc. I am not a fan of having to use a million cloud services these days.
Why is this even a question, seriously? The cloud shouldn't be the first option - I'm immediately turned off by this product if that is how its going to work.
Yup. I want to be able to run the cloud service on my own hardware.
Now, if they offered actually-secure client-side encryption (with no backdoors or sidechannels to strip said encryption, unlike e.g. Mozilla do with their accounts), then I might still be interested, but I'd still rather run it on my own hosts.
They use a protocol where they never have access to your password (and the secrecy of all the data they store for you hinges on the secrecy of your password), which sounds awesome, except that they serve a webpage to handle logins to their accounts, which means they can (& can be compelled to) serve you JavaScript which sends them your password out-of-band.
These two factors (all secrecy depending on your password and their ability to get your password) mean if you can remember your password, then Mozilla can brute-force your password, and if you have a strong password (e.g. 7HlipLbGliwUmUdWHKeq4p), then Mozilla can — or can be compelled to — serve you targeted JavaScript and steal it.
> Imagine for a company only five years back to literally say that your thoughts are sent to their server.
Well, now or five years ago, no one had the mind reading technology to say that, literally.
However, it's worth noting that Chromebooks were introduced five and a half years ago, so for a company introducing a device line to say that your work would be synced that way 5 years ago isn't something you have to work hard to imagine, if you were paying any attention at the time.
At first glance, it seemed like yet another silicon-valley-neoliberlist-style lots of words and ideologies, but no code and practicalities. But it seems like OPs thesis has a more hands-on approach:
- It seems some kind of language/computation-model. Loosely based on a "everything is an actor" model.
- It did look goodish. I tried following the Fibonacci example, which sort of made sense (I got the impression that recursion is handled by creating new nodes/zells). The discussion chapter also seemed interesting.
- It has that abstruse academic feel, where sometimes it is hard to assess whether the problem is my ignorance, or just vagueness of the publication.
- Motivation sections usually have an exaggerated tone to them (i.e. this will totally change everything), but this one, and the article above, are a bit over the top.
- There are also some over-the-top statements sprinkled throughout the thesis (e.g. "a model of virtual objects which exist independent of any hardware").
- that's exactly what it is. And the way I see it, actors are an implementation of OOP (in it's original meaning) so I would stick with "everything in an object"
- thanks =)
- I had that same feeling while writing it, constantly balancing my own ignorance with an acceptable level of vagueness
- call me the over-the-top guy. But the way I see, your vision has to be grand, if not megalomaniac if you want the essence to survive the collision with reality
- seamlessly migrating networked objects are one of the lesser over-the-top ideas though
If the thesis is relevant at all to what you're doing now, might I suggest linking to it directly from the manifesto? Otherwise it sounds mostly like you are very excited about something, but I got almost no idea what that something is.
That's probably the biggest weakpoint of the manifesto but also kinda on purpose. While the thesis was all about "let's build something" the manifesto is a fresh start trying to answer the question "what is the problem?". The thesis is still relevant but a bit outdated and I'll probably rewrite it in multiple blog articles.
What I'm planning to use as information starting point is zells.org but it's all still in an early stage. At the moment I'm working on creating a document that visualizes the "end product" that I have in mind.
After looking at the thesis and the manifesto, I think your best bet is to create one worked example, in pseudo-code or whatever, and then see if you can get anyone on board with that.
This looks interesting to me as a programmer, but it looks much too complex and niche-knowledge-dependent to be, in my opinion, a real contender as a tool to allow non-programmers to program.
I only glanced at it, though, so maybe its easier than it seems, but to me, the samples looked complex enough that I don't see it.
It does look great as an experiment into different programming models though and that's something I always enjoy (and is needed if we're to get better future tools).
At least in the case of free (as in freedom) software, the vulnerabilities can be exposed and patched. More importantly (and more relevant to this discussion), software freedom also tends to make it difficult for the original developer to hide malicious features.
Theoretically, yes, but if you're going to make that claim you'd need some hard data showing that exploitable bugs either happen less frequently or are going and patched earlier.
To be fair - they didn't make that claim, just left it up to you to assume the dichotomy.
It can be (and arguably is) true that "proprietary software is inherently insecure" - without requiring an opposite statement like "open source software is inherently secure" to also hold. (The wording in context _does_ strongly suggest that was the implied premise of the implied premise tho.)
How can I obtain reliable data on non-free software when the public cannot study the source code?
You also seem to discount the possibility of _intentional_ vulnerabilities (from the user's perspective) being included in the software by its developer.
You appear to be unaware of the large industry reverse-engineering software of all sorts. You could compare comparable projects and see whether source availability correlates with fewer vulnerabilities, lower severity, etc.
Similarly, the security community has discussed the possibility of intentional vulnerabilities in opensource software for decades. Sure, someone would probably notice if you submitted secret-nsa-exploit.patch but it's unclear that someone would notice if e.g. you submitted a Heartbleed-style bug, not to mention something the NSA's dual curve backdoor.
To be clear, I've been working with open-source software since the mid-90s. I think the model has a lot to offer but it's not magic. Lazy fanboy activism doesn't do anything but lower your credibility and help the companies which are arguing that open-source isn't safe to use (or isn't safe to use without paying them to manage it).
