Standalone Signal Desktop(signal.org) |
Standalone Signal Desktop(signal.org) |
https://github.com/WhisperSystems/Signal-Desktop/issues/1632
Also a bit annoying that it can't be run in the background, at least on Windows.
https://whispersystems.discoursehosting.net/t/new-desktop-ap...
The solution is to build a common Electron runtime that all Electron apps can use. But it seems nobody is working on it despite all the complaints.[1]
I really don't understand why there isn't anybody working it. If that got implemented, it would put a swift end to the biggest complaints about Electron.
Qt, Gtk, .NET, Java, Android, Cocoa, UI Kit, KHTML, even crufty old Motif had such widgets.
It is just web developers not getting native development.
A common runtime would be as if you ran five Node.js apps using the same runtime and opened five tabs in a single instance of Chrome.
I'm not super well versed on the low level implications there, but I find it hard to believe that wouldn't save a lot of resources.
I mean, do .NET apps load up a full copy of .NET and all its libraries into memory for each app you open?
Kinda the Wechat model
So it is not _really_ standalone. You still need a phone. This is still a geeky version of WhatsApp.
In fact, why would I want to use this instead of WhatsApp if they're basically using the same encryption features and I have to trust the same people (who assert that)?
(I don't use WhatsApp, I think it is the worst mankind nightmare.)
Yay...
From the bottom of the main page on their website. I removed the marketing copy.
I'm very happy with it nonetheless!!
Desktop apps are supposed to be: native code, well integrated in the OS, still working when the net is down and using system widgets and OS look&feel.
Thank you but I'll just keep using Wire on the desktop and Signal + Wire on mobile. Too bad, because the mobile version is really good.
For me desktop apps are apps that run on my desktop computer, requiring an installation process instead of being loaded via an URL and not subject to the browser's sandbox.
I've had access or owned desktop computers in various shapes and sizes ever since 1993 and let me tell you, since then until now the notion that desktop apps have a unified look and feel is a really recent phenomenon, that happened due to Apple, OS X and the iPhone.
Yes, even Windows 3.1 had standard widgets but historically standard widgets haven't been expressive enough and many developers did not care anyway, especially since most apps were reincarnations of former DOS apps or ports from other platforms. And then the birth of Java made it much worse.
E.g. the most popular MP3 player ever on Windows has been Winamp. Besides the file opening dialog, there was nothing standard about it. Most popular chat apps several years back? ICQ and Yahoo's Messenger. Have you been acquainted with their UIs? In terms of nativeness, let me tell you, the web-enabled Facebook Messenger and Hangouts are improvements, because at least they don't mess up the text rendering.
The Apple HIG dates as far back as the Macintosh. That’s 1987[0]. Visual and behavioral consistency have always been a staple of good design for those who cared.
[0]: https://guidebookgallery.org/books/applehumaninterfaceguidel...
That excludes every single .NET application.
> well integrated in the OS
Don't even know what you mean by this.
> still working when the net is down
Not necessarily, a "native" app for Signal still wouldn't work if the net was down.
> and using system widgets and OS look&feel
I guess that excludes pretty much anything built with Qt.
Sure I can understand the reasons behind it, it's JavaScript, programmers for that are abundant, is multi platform because web, but still. If you look at the functionality offered versus the resources used it's just ridiculous.
I'd like to see a graph of code/memory used vs unused in such binaries.
I know Discord doesn't support using a keybind for push-to-talk whilst the (Chrome) tab is not in focus with their web application whilst their Electron app supports this. Something vital to PTT users whilst playing games.
there is a certain section of third party app-developers that argue that app ux should absolutely emulate the host operating system. when this isn't sufficiently expressive, new interface elements should be designed such that they blend in naturally (ie, resemble what likely would have been the os-developer's choices).
Electron is an hybrid codebase to start with.
If they need to interact with the host OS, someone needs to write those native plugins, and that won't be in JavaScript, as the Github repository for Electron clearly proves.
In the end is all about using an hammer for everything.
You can write Qt apps entirely in C++ or entirely in QML (of course you can mix and match both... in my experience whatever the environment you always need to resort to native modules at some point anyways, eg numpy, opencv, etc and Qt makes exposing them to Javascript dead easy).
Look, you can call it "using a hammer for everything" pejoratively if you want, but it's popular for a reason, and that reason isn't the moral decay of society. It offers real utility that reasonable people find valuable for rational reasons.
Which happen to be written in native OS languages.
“Hybrid” does not mean what you think it does. The platform may be built on code in many languages, but to program for that platform, you only have to know one.
Using your example, C is native, Python is not.
I cannot run another Electron app on my computer, I simply do not have the RAM left. Signal as a web-app would allow me to put it inside of Franz or Rambox, where all my other chat services live.
Right now Signal is the only chat service that I cannot run in Rambox or a browser.
All the other major chat services provide a web-app that can run in a browser:
- messenger - whatsapp - wechat - hangouts - skype - zulip
These apps all have web versions for good reason, a website is the most versatile, portable way to share an application with users who's devices you cant support individually. If a user's chrome extension gets hacked a steals their messages that's their fault, it should be the choice of the user whether they run the app in an insecure environment. After all, you're relying on them to not have keyloggers or rootkits on their computers that run the desktop app.
I don't see any reasoning for Signal to not follow WhatsApp's model and release a web-app that links to your phone.
The service (either intentionally or by virtue of being hacked) can serve up Javascript crypto code that either uploads plaintext, or subtly backdoors the crypto so it can be decrypted. And they can do this to just a single user, so unless you audit the Javascript every single time you load the page, you'd never know.
A signed app is more secure, because a backdoor would have to be distributed to everyone, greatly increasing the chances of it being discovered.
Furthermore, we're using their website to download the Desktop app, the binaries are neither signed by them nor by Apple (or macOS). So the threat model is "almost" the same here as a web app here except for:
* CSRF would not work on an Electron-based app.
* Trusting an Electron-based app is a one-time thing (close to a Trust-On-First-Use trust model). (thx Nik Kinkel for pointing that to me.)
[1]: https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
That said, at least they have the option of closing that hole with the electron app.
You could indirectly solve this problem by making some sort of electron multiplexer that could take multiple electron apps and make them share the same electron host browser, achieving the same thing you have now.
I personally just use a bluetooth keyboard and my phone. I get a native app, keyboard typing and nothing hogging resources on my computer.
A fresh launch without logging in or having it run for any period of time immediately uses 211.2MB:
1. Signal: 58.3MB
2. Signal Helper: 128.6MB
3. Signal Helper: 24.3MB
- It said it was 'Importing contacts and messages' when I signed in without first prompting me if that was OK.
- Importing contacts and messages failed.
- Manually importing contacts fails.
- Conversations show up, but each message just shows as an error.
- Deleting a conversation doesn't delete it, it just makes it as read.
- Messages marked as read randomly reappear as unread.
- Incorrect unread message count next to conversations list.
- Messages often don't arrive at all, seems at random.
- The application loses it's 'link' to your account seemingly at random upon launch and needs to be relinked.
- Appears to use an outdated version of electron with published security vulnerabilities.It uses 130MB RAM here (Win). How much is it on your side?
We seemed to get by with MSN Messenger with far less RAM, and the features were pretty much identical.
It boggles the mind how memory-intensive some of the modern apps are. It's insane.
It seems to me that many Electron apps these days are super-thin wrappers around a web app that don't actually need the full desktop access offered by Electron (things like local filesystem access, multi-process execution, multi-window management, arbitrary node APIs, etc).
They just need a way for users to "install" the app so that it 1) has a separate shortcut and appears in a separate window from the browser, 2) can send notifications through the native notifications stack, and use a fallback on systems where one isn't available, 3) is available for use offline.
The Progressive Web Apps spec has answers to all of these problems, and it would vastly improve the resource usage model compared to Electron because each PWA would share the same browser runtime as the user's browser of choice, which is more likely than not running 24/7 anyways.
Security-minded apps like Signal might need more guarantees such as asset verification and version pinning on install, but surely those could be added to the spec, as they would be beneficial for other Progressive Web Apps as well.
I know PWA was designed with mobile apps in mind originally, but it'd be a shame to limit it to that use case, as there is clearly a lot of demand for building desktop apps with web technologies, and PWA sounds like an excellent alternative to the current status quo that's dominated by Electron.
The web platform is a really great example of backwards compatibility - it has to, because people wouldn't tolerate breaking changes to websites. Browsers (and Electron) have made a lot of progress in the last years, but now I think this platform is very capable and you can get a lot done without waiting for a new feature. This makes something like Electron a good candidate to ship with the OS. Remove the burden of updates from the individual vendors, and use a lot less disk space and memory because there is only one runtime.
I don't see installable Electron any time soon, but interestingly Edge might fulfill that role on Windows (if it is compatible and PWAs are powerful enough to replace most electron apps).
I am very privacy conscious, and I don't use a smartphone, at all, because it's basically a spying device in your pocket.
Why Signal is all about privacy and then it forces me to pair it with a telephone?
Telegram desktop is really standalone. They require a telephone number too (and that's very annoying), but they don't require having a smartphone or keeping your phone open. My phone number on telegram is not even my phone number anymore, and it doesn't make any difference... Privacy wise is far from being perfect, but it's already better. At least it's usable.
To me it's simpler and works better than Signal while being decentralized and federated. It has excellent clients for all platforms (and these keep measages in sync with each other) and does not require a phone number.
There's a fantastic one in the works, qmatrixclient (quaternion: https://github.com/QMatrixClient/Quaternion), but it doesn't support E2EE yet.
The developers badly need to invest in a UX engineer, but are currently stuck scrambling for money as their corporate sponsorship ran out.
I've also stopped using an IRC client and just use a Matrix bridge. Really happy so far.
Main drawback is that E2E is a bit clunky to set up, and downright confusing for non-technical users.
For an app that is supposed to be the pinnacle of secure messaging, leaving anything unencrypted on the local device is just breathtakingly negligent.
The way moxie ushers people to take the discussion elsewhere doesn't help either. It just reinforces the perception that he doesn't care.
The people in the report (not necessary the original submitter, the "Now I'll go and tell everyone to uninstall Signal! There you have it!" crowd) seemed to be demanding/whining and spammed a bug tracker with random anecdotes and their personal agendas in a rather rude way.
Whereas moxie - again, in my opinion - replied in a very friendly, objective and calm manner and invited these people to discuss the issue further. In the _right place_ for an open debate about design decisions.
Guess you can never please everyone.
But in all seriousness thank you for the great work, this is excellent news!
$ curl -s https://updates.signal.org/desktop/apt/keys.asc | sudo apt-key add -
$ echo "deb [arch=amd64] https://updates.signal.org/desktop/apt xenial main" | sudo tee -a /etc/apt/sources.list.d/signal-xenial.list
$ sudo apt update && sudo apt install signal-desktop(To be a bit more explicit: searching for either the pub (57F6FB06) or sub(0E46390F) keys on hkps.pool.sks-keyservers.net returns no result)
It's ludicrous that you can't download a security-focused app when your browser settings are unusually secure. ;)
Inspecting the app, it appears to be just another Javascript app (Electron).
Oh come on guys. Don't forget Fedora. Fedora means SELinux. SELinux means you are getting the people who value security.
Proper, very strict sandboxes implemented with seccomp & friends are much more secure. You simply block the large majority of system calls.
Surprisingly, they are often easier to set up.
Maybe that's just me, but it's good news!
So, you're migrating from Firefox to multiple instances of Chrome...
Am I the only one who thinks this defeats the whole point?
Signal feels slightly like the pigs in Animal Farm getting everyone riled up against the unjust farmers, only to take their place.
edit: And anyways, if you read their blog posts you can see how you phone number is only required to make it easy to connect for the masses. You already have your social graph in your contact book.
Really happy to have it as a standalone app outside of Chrome now.
Signal support is coming later this year. Right now it supports Slack, Skype, Facebook, and Gmail.
So this isn't light or native. It uses the same Chromium codebase, but atleast twice the size of Electron apps.
https://hardbin.com/ipfs/QmNttGPf65DZ3eeuNCCWemrxyNzaHxLhpAZ...
If the rest of you are wondering where the bulk of it came from, check libcef.so (466 MB)- which is Chromium Embedded Framework.
Franz https://github.com/meetfranz/franz
These are similar apps. Though they do use Electron, they let you share one Electron instance for all your chat services.
window can't be resized, standard menus are missing, standard keyboard shortcuts for text fields don't work, conversion text can't be selected, no way to cut or copy text (tho paste does seem to work).
is it implementing its own ui toolkit? qt maybe?
I could understand if it was a GB or so, but in this day and age it's USD 9c or less worth of disk space (assuming you use high end SSDs, if it's a HDD then it's under 1c).
So I guess there is a way to use signal without having a phone nowadays! That's a great news!
I will try right now.
How did you evaluate Telegram to decide that you trust it?
It’s got a pretty bad case of kitchen-sink flat ui, but is otherwise not bad.
I know it's open source, but modifying it and recompiling all the clients I'm using would be very annoying.
My personal computer runs an open source bios (coreboot) with an open source operating system (linux) and no closed source software (at least one of my PCs does). My phone on the other hand has many processors running on it (that I know about) that can interact with my device without me knowing and binary blobs (yes even with lineageos and with microg) that I can't control and many parts I can't update or update as fast/easy as my pc.
My point: for most people the attack surface of the smartphone is far larger than the attack surface of the PC
https://chromereleases.googleblog.com/2017/07/stable-channel...
https://chromereleases.googleblog.com/2017/09/stable-channel...
https://chromereleases.googleblog.com/2017/10/stable-channel...
Equals ~169MB (I've just sent a picture)
Which they don't. That's why it's not a web app.
I mean isn't one of Signal's target audience people like journalists and activists?
If you(r system) trust the certificate that https://updates.signal.org/ is using, you should be confident that you are getting the correct keys.
(You shouldn't trust a stranger on the internet, but I am getting the same keys when I download them.)
However, Debian is shipping a number of hardened systemd unit files.
To see some examples on how the sandboxing is being set up you can grep for SystemCallFilter, CapabilityBoundingSet, ProtectSystem, ProtectHome in /lib/systemd/system/*.service
My main problem with Rambox when I first tried it was that it couldn't remember my sessions across restarts for some reason. A quick test shows that Franz doesn't have this problem.
Also, the API for adding new integrations looks delightfully simple [1]! I'll probably take some time over the weekend to try to port over some of the things I use frequently that aren't yet available. Though it'd be even better if it offered a first-class escape hatch to add simple integrations through the app itself like Rambox does.
[1] https://github.com/meetfranz/plugins/blob/master/docs/integr...
Security is about threat models: if you don't trust the code they write on their website, you shouldn't trust the code they shipped in the app.
Without having a smartphone, using Signal wasn't an option (at least previously).
Sadly, almost everything involves tradeoffs.
He (understandably) prefers to use a tool which doesn't require a phone, over one with a better security model.
That said, I could not get the app to work with Google Hangouts or Facebook Messenger after 5 minutes of fiddling, so I gave up.
I'll switch to Servo in the future, it's only ~20MB.
Right now the focus is on features and performance, but the app is going to be polished before the 1.0 release to have a more native feel: native notifications, shortcuts, textfields, etc.
(actually, i'm not sure if it's possible to make your app friendly to screen readers w/o using native widgets. maybe?)
if you do pull it off, you'll end up with a great ui toolkit for go. that would be a very interesting thing!
[1] https://githubengineering.com/how-four-native-developers-wro...
[2] https://slack.engineering/growing-pains-migrating-slacks-des...
* run rendering in a sandbox
* closely monitor your deps for vulnerabilities and ship patches as quickly as possible
* choose deps with a better security track record, when possible
* independently scan, test, and validate the deps you bring in
things you can do in an electron app:
* pray
> run rendering in a sandbox
Most major browsers, including Edge and Chrome, do this and are really good at it.
> closely monitor your deps for vulnerabilities and ship patches as quickly as possible
Most major browsers do this too, and they have well-established update pipelines that can patch vulnerabilities in short order.
> choose deps with a better security track record, when possible
Most major browsers do this (e.g., "boringssl").
> independently scan, test, and validate the deps you bring in
Most major browsers do this as part of QA and vulnerability scanning.
> things you can do in an electron app: > * pray
* leverage all of the work that thousands at Microsoft, Google, Mozilla, etc., put into deploying what I suspect are the most heavily-attacked, heavily-scrutinized, and heavily-audited software platforms in existence.
Not that I'm specifically advocating web apps over native apps, but I don't think your list does a good job outlining their advantages.
source https://gizmodo.com/why-you-should-stop-using-telegram-right...
For me, the problem with Signal is based mainly moxie's position on the LibreSignal fork, which aimed to be a Google-Free version of signal, but moxie said he was not OK with LibreSignal using the Open Whisper Systems servers and the name "Signal".[1] I kind of understand his position, but that's not what I'd expect of the free software community and definitely not what I expect from someone who's in the middle of my communications.
In the end, the hope's in matrix.org. It supports end-to-end encryption, works without a number and is fully federated. Maybe someday Telegram and Signal can even federate with matrix.
[0] https://telegram.org/privacy#2-storing-data [1] https://github.com/LibreSignal/LibreSignal/issues/37#issueco...
He only wants users to get Signal builds from himself, and no one else.
Moxie is most decidedly not against building the code yourself. He doesn't want anyone distributing forks or other clients using the official servers because a) that creates a giant hassle when updating the server and suddenly someone's fork doesn't work anymore and people will blame Signal, and b) if the client doesn't do what they want it to, people will blame Signal even though it's a third-party bug because it's got Signal in the name.
Moxie has publicly stated that he is against anyone publishing a third-party build of Signal.
He has openly and loudly ranted against F-Droid. Of course he's not against users building it for themselves, but he's publicly stated he won't allow F-Droid, or distributions, or anyone else, to build and publish the client, under the name Signal, so that it can connect to his servers.
Read the Signal-Android issues https://github.com/WhisperSystems/Signal-Android/issues/53 https://github.com/WhisperSystems/Signal-Android/issues/127 https://github.com/WhisperSystems/Signal-Android/issues/281 and https://github.com/WhisperSystems/Signal-Android/issues/6292, where moxie publicly states that he will not accept or allow any public distribution of third-party builds of Signal to connect to his servers.
He actually directly reached out to F-Droid, and demanded they take it down: https://web.archive.org/web/20160410152543/https://f-droid.o...
So, how the fuck is what I'm saying misleading?
EDIT: Oh, right, some of the linked issues were purged by him later on. Here's an archive.org link: https://web.archive.org/web/20160410153027/https://github.co...
EDIT2: The real question is why you continue to lie to defend Signal.
On the topic of LibreSignal, a fork with the only change being that it supports notifications without relying on proprietary libraries:
> I'm not OK with LibreSignal using our servers, and I'm not OK with LibreSignal using the name "Signal." You're free to use our source code for whatever you would like under the terms of the license, but you're not entitled to use our name or the service that we run.
https://github.com/LibreSignal/LibreSignal/issues/37#issueco...
Basically, he argues that no one but him has the right to build a client that connects to his servers.
Disclaimer: I personally am critical of Moxie's demands that he fully controls all released client builds, servers, and his use of analytics.
And much of the stuff on the Linux side seems to be driven by upstream (Flatpak in particular has come out of the Gnome camp), and is riding the "containerization fever".
"Oh no I can't use that business chat tool, it doesn't support smiley faces and cat reaction gifs".
Also, if you're relying on a stupid cat gif to judge your colleagues mental well-being (and you are concerned about their mental well-being), perhaps you need to spend more time talking to them and less time searching for dank memes.
The key thing Slack offers most 'customers' (even those who don't pay) compared to something like IRC is the simple setup/use.
I say this as someone who hates Slack, but has had to endure it on a number of client projects.
Edit: It actually has the option to register without smartphone, but it's only enabled in the debug versions.
This might get you started: https://github.com/WhisperSystems/Signal-Desktop/blob/d1f7f5...
But with that interpretation (and the context around that, where users asked about including it in distros), my arguments are certainly relevant.
> If you read the issues you so kindly linked, he explains his reasons, and they are valid points to make even if I don't like their consequences.
His points are basically irrelevant if compared to the risks that the centralization causes.
Users of distributions have to trust their distro anyway, for many other packages (including the kernel build) already, trusting them for Signal, too, actually reduces the number of parties you have to trust.
The issue with not encrypting in transit by default is that it makes profiling encrypted communications MUCH easier and can potentially defeat the purpose via the Streisand Effect.
(Oh, and worth noting: it has an integrated update checker, so not being in F-Droid is less of a problem.)
3 of those 4 things I would class as "simple setup/use".
I can imagine someone saying "we switched to/chose Slack/HipChat/etc over IRC because it's much simpler to administer and a lot more user-friendly for people to communicate with the team".
I cannot imagine someone saying "we switched to/chose Slack/HipChat/etc over IRC because I need my daily dose of cat reaction gifs"
An update checker is nice though! I wish firefox had one, but at least there's FFUpdater.
Nor would I since it still requires a phone number to use.
That large companies also do this is another story entirely.
The GUI used wxWidgets using C++ and included a 3D section for system layout (using OpenGL). All of the 2D GUI controls for the rest of the system were "owner-drawn" which means that they overrode the ::OnPaint and drew themselves so as to look different than native controls (as audio systems always have to "look different").
This means buttons, toggle buttons, radio controls, control surfaces, sliders, meters, compressor meters, knobs, graphs, charts, lists, grids, EQ control graphs, everything. There were no native controls other than in popup dialogs (like saving/exporting). It redraw every 50ms based on data that it was receiving over the network from a series of hardware, with this data logged and processed in background threads. It used less than 1% CPU and a fraction of the RAM mentioned here for a chat app, even with cached in-memory bitmaps that it generated in code for drawing.
This ran on Mac OS, Windows and Linux. This means a native binary on each system. It can be done.
It is wrong to say that this embedded-web-app way is the "only way" of doing it. Not to be rude, but it just means that the devs can't be bothered to do it another way.
And that was me writing all of it, plus one guy who did the networking library. Two of us.
How can they "not have the resources"?
Web dev tends to optimize for ability to change/improve quickly (for good and bad). Resource use on the computer typically not prioritized.
I feel Signal should have implemted the core messaging components as a non-gui program or library or plugin to another Messaging app (e.g. Pidgin). Then if they want their own app, they could have used a lightweight cross platform window toolkit (e.g. WxWidgets or Qt).
I've got a lot of tabs open right now and I'm not sure how to read the memory usage in Chrome's task manager, but Chrome appears to claim to be using about 450MB just for the browser, plus some additional amount for each tab I have open.
Last time I've had it installed it was something close to a gig. But then it became a cluttered monster I rather fear so that's not relevant anymore.
Same goes for this. I'm happy to give that RAM to Signal since what I get for it, is more then worth it and I have the RAM left. It took me more time and headaches to get people to use Signal on their phones in the first place than it will ever for that 130MB RAM.
If efficient use of something like RAM is blatantly disregarded, what about more important things like performance-critical sections of code? Would you be happy that it is shoddily written?
The same approach on a mobile device would be widely condemned due to the hogging of RAM. I don't see why the same metrics cannot be applied to desktop software.
Is the solution for badly-written slow software "just get a faster CPU"?
I would like if it could use less resources, minimize to tray, etc. etc. etc. but for the moment, this is good and the RAM usage is a far less dramatic issue to me than it seems to be to many here.
I mean, there is far worse out there. I sometimes play Elite Dangerous on my other Win machine. There is a community build tool to track your flight route from the games logs (EDDiscovery) and it delivers an endless amount of features. It rests on a pretty huge database. This thing eats up my ram like it's some free gigabyte cake. I even have to launch the game first or it would take forever. It's horrible. The tool is great though and I will have it running when I need it and it does not hurt my remaining experience. I would love if it could use less resources but I won't stop using it because of it.
Everything about skype indicates that it's badly written. This is a text messenger that can't handle copy and paste operations correctly.
-- Niklaus Wirth
a. A smaller executable that makes efficient use of your machine's resources
b. A developer with less knowledge and experience who is able to write a memory-hogging desktop application
Electron is several things which HN guidelines probably won't allow me to describe here. I avoid it whenever I can.
Whether you consider JavaScript a sane language is up to you. :)
For audio hardware, you don't want to be grabbing software + firmware updates multiple times a week. You might be on tour with the hardware and changing it whilst on the road is likely a no-no.
I am now at a place where we ship daily, sometimes multiple times (different branches). The emphasis on decent code and quality is now higher than the previous place I worked. The codebase here is also incredibly vast by comparison.
We can still add features quickly but it is of little use if it is of poor quality. What's the point of bad software even if it is quickly shipped?
You may even embed some web-engine. It doesn't have to involve obscene amounts of megabytes and the selling of your soul to the Google monster.
Some bugs here and there but paired with a tool to layout UIs (like wxFormBuilder), you can get a lot done.
It's a pity, because Lazarus does seem fantastic for desktop application development...
