Why Python?

[chan] bitmessage
Aug 7 10:33

Why is BM written in Python? I understand that it is safer wrt memory management issues which C and C++ are notorious for and it runs on all systems that have Python. But why not Tcl/Tk or Java?

[chan] bitmessage
Aug 7 15:36

because the dev knew python best. why the fuck do you care? Don't like it? Then port it to some language that you know. Stop cribbing.

[chan] bitmessage
Aug 7 22:57

As other experienced Devs here have pointed out, several times, the effort in coding directly in C/C++ is unlikely to yield any significant improvements worth the enormous effort in recoding. cpython can be built highly optimized for specific environments if you don't mind the effort in building the tools that write the privacy tools. It is an abstraction that provides enormous productivity gains and least distraction from low level coding issues. As the name suggests, it is the python implementation ( a higher level abstraction ) built *IN* C/C++. Lots of luck coding in "Safer" languages, like ADA; even if you have a generous government military budget to do it with, it will probably fail to deliver in other ways. Why custom build cpython? To get the most recent security fixes and bugfixes, and to select exactly what ssl/tls codebase you run at the sharp end on hostile network connections. From memory there are quite a few mercurial repository commits to python 2.1.13+ that wont be seen in packaged distro python implementations for quite some time: memory fragmentation improvements and tls timing improvements as but two examples. As someone that sat in on many OxBridge University academic seminars with visiting specialists involved in java efficiency and security tradeoffs I can tell you right now that java would be a lousy rebase alternative, and also not worth the effort that porting the present PyBitmessage implementation would involve. The Biggest objection that I have to Python in the context of this project are the daft decisions in Python3 that effectively make many projects impossible to convert to later versions of 3.x GUI "widgets" being just one example. I have a problem security wise with most languages that use autotype conversions internally to make programming easier. Complex specifications (such as UTF) always have implementation grey areas that are ripe for code abuses ( run fuzzing tools on those code modules for nasty surprises ). The changes to string handling in Python3 do offer smaller grey areas to attack, but I have no appetite to learn two parallel coding approaches to string handling. Python2 codebases and development are pretty much here to stay and I do feel sorry for the poor Barstewards that have to code both professionally, and will be lumbered with this misery for most of their programming careers - maybe more than half of their productive years if just starting out recently! This fact alone should be sufficient to lose Python its "market share" as better language implementations evolve into mainstream use; ones that promise easier continuity and experience "re-use" - not just code re-use. I hope that I have provided a little less noise and some insight. There are open access references to the fine details of java and python mentioned here for the inquisitive if you search for them. *PLEASE do NOT bait the Developers* This project almost stagnated once. I for one am extremely grateful that Peter Surda, and others have pitched-in rather than stand on the sidelines bitching but not contributing anything useful. What they are doing is HARD WORK, with little prospect of any reward in the short to medium term. I'm just cruising in their wake trying to learn a little about how the best pythonistas operate. Personally, I've no chance of ever reaching their level of competence, no matter how much time I divert to that end. Mere "Thanks" are completely inadequate. When you work at the bleeding edge, as they are doing, with real-time complex network code, you WILL be making spectacular mistakes as part of the learning process. They can spend what little time they have blogging about it all and media-whoring, but then they wouldn't have ANY time to code. It is irritating to find that things do not work as the boolean selections might suggest in the sections of code you've altered. Or configuration options that do not behave as expected. Been there MANY times myself since 2014 :- Tough. *Get over it*. The polite thing to do is send a synopsis of your issue by private message and find out WTF went wrong BEFORE going public with a Hissy Fit. Everybody Loses if you do that. I've annoyed these guys enough with distractions privately, but always received a polite and reasoned response as a gesture because of the courtesy I extended by starting out in Private. We need a Benevolent Dictator to decide the best direction the code must take. Its better that the more difficult exchanges are attempted privately first. Then the public side sees the compromise without all of the noise and bad humour. All thats left after that is to decide the best form of funny walk and salute to use at events where you meet in person ;-)

[chan] bitmessage
Aug 8 00:39

> the daft decisions in Python3 that effectively make many projects impossible to convert to later versions of 3.x Screw python and the python leaders. They won't let you use brackets instead of indents, they messed up the syntax into obscurity with the upgrade from 2.7 to 3.x, which caused mountains of 2.7 code to become obsolete. Most of the problems come from nobody looking at the big picture before they decide to reinvent the wheel. Most of my debug time in Python is finding and fixing indentation problems. Everyone in the programming world knows better than to use indentation as a syntax.

[chan] bitmessage
Aug 8 00:56

> But why not Tcl/Tk or Java? Java? Are you kidding? One of the slowest development times of any language? Tcl / Tk code for anything larger than an egg timer becomes impossible to understand or maintain. Tcl is an amazing language that allows really slick solutions, but any large codebase is unmaintainable. Pascal would be an improvement, and reads similar to Python, but has little community support and only a fraction of the libs of Python. It is less cryptic than C, runs as fast as C binaries, and is still used religiously by many large companies because of how much work time it saves--until you need a library that does not exist. How about Objective C? Using the reflective syntax features would be great for cryptographic logic, still close to regular C speed.

Aug 8 04:34

Bitmessage was already in Python when I joined the project so I didn't really have a choice there. There appear to be some low-level things (string handling, concurrency with threads) which I am unhappy about and find slow in Python, and am pretty sure would be faster in C. I did a lot of profiling in the current release cycle so I have a much better understanding of where the bottlenecks are. That being said, I think most of this can be worked around. For example the network subsystem can be in the future switched from multithreaded queues to multiprocessing queues, which will avoid the GIL bottleneck and gain better scalability. I'll do that when it makes practical sense. The string handling performance can probably be worked around as well. Sqlite interface can be switched from a queue to direct calls on systems where sqlite has concurrent access support compiled in. Especially older versions of python have inflexible SSL configurability (it has been improved in python 2.7.9). Similarly, most of this can probably be worked around, for example when I add authentication to TLS, that should allow python < 2.7.9 to act as a TLS server. I'm not sure regarding TLSv1.2 support in python < 2.7.9 but will have to examine it as Debian recently announced they are disabling TLSv1.0 and 1.1 support in shipped OpenSSL and this may prevent nodes with older python versions connecting with nodes running new Debian. I don't like java but can't say why exactly. Maybe the complicated build environment and that it's slow to start? Dunno. Anyway there is now a java implementation of Bitmessage called Pechkin, developed by Alexandr Fenenko: https://sourceforge.net/projects/pechkin/ Peter Surda Bitmessage core developer

[chan] bitmessage
Aug 8 05:13

much of bitmessage could be refactored with NUITKA, the python compiler. It generates very efficient machine code and gives much better performance enhancements than cython. What is Nuitka The TL;DR ... Nuitka is a Python compiler. It's fully compatible with Python 2.6, 2.7, 3.2, 3.3, 3.4, and 3.5. You feed it your Python app, it does a lot of clever things, and spits out an executable or extension module. Free license (Apache). Okay I'm hooked! Tell me more! Now Right now Nuitka is a good replacement for the Python interpreter and compiles every construct that CPython 2.6, 2.7, 3.2, 3.3, 3.4 and 3.5 offer. It translates the Python into a C program that then uses libpython to execute in the same way as CPython does, in a very compatible way. It is somewhat faster than CPython already, but currently it doesn't make all the optimizations possible, but a 258% factor on pystone is a good start (number is from version 0.3.11). It's in ubuntu repos. $ apt-get install nuitka NUITKA(1) User Commands NUITKA(1) NAME nuitka - the Python compiler SYNOPSIS nuitka [--module] [--execute] [options] main_module.py

[chan] bitmessage
Aug 9 01:34

> How about Objective C? There'd go our Wandows support. > Java? Are you kidding? One of the slowest development times of any language? You can sidestep this by using another language on the JVM--maybe Scala. Sure the systax'll make your eyes bleed, but SPEEEEEEEEEED!!!!!11one Regardless of the language, is anyone up for removing the Application GUI and just having a web interface on localhost? It'd be really nice for modularity.

[chan] bitmessage
Aug 9 01:55

> Regardless of the language, is anyone up for removing the Application GUI and just having a web interface on localhost? I already started the framework for a browser client. I created a secondary channel on the SimpleXMLRPCServer that serves the http content to the browser and accepts both XML and JSON API calls back and forth between PyBitmessage and the browser (or even cUrl) using straight JavaScript (no jQuery). With that set up I stopped. I want to wait until streams are implemented before I do all that work. We already have the QT GUI. There's no use in me coding a JS GUI until PyBitmessage is a bit more mature. Streams have to be working and able to scale the traffic to a massive user base (at least a few million peers) before I want to put effort into a fluffy and unnecessary client.

Aug 9 07:12

PyBitmessage can run in a headless mode and use the API to provide an alternative UI. Although I think the API could be enhanced as some features aren't available there. I believe the current API is compatible with browsers (there were some incompatibilities but I think someone suggested a fix and it was merged). So if someone provided a Web UI that I could bundle, I'd be very happy. Similarly for an IMAP interface, I was unable to find a IMAP server library for Python. Peter Surda Bitmessage core developer

[chan] bitmessage
Aug 9 10:29

Pff. Fuckin AAPL walled garden shite.

[chan] bitmessage
Aug 9 14:28

I think that it needs a RAD minimal GUI that has multi-platform capability (Qt) and minimalist "sorta-GUI" ncurses until the final scalable version of Bitmessage can be taken seriously. You can tweak things and examine the keys.dat effects (easily) and internal stored states in messages.dat (MUCH harder) as new features emerge to real world usage cases and operational issues. Always surprises there. At that point there needs to be some specialisation and division of effort when (say) a definitive API and core is "sealed" as a design. There may be further fundamental protocol - not just implementation changes needed. Quite likely, I'd say. What makes me twitchy is the possibility that valuable Dev time might be wasted on fancy GUI front-ends in the mistaken belief that it would make in more "marketable" and apt to persuade ordinary folk to switch away from email for all personal communication completely. There will be a time for that. But its probably many years from now. Consider the massive stupidity and waste of time that something like MickeySoft Word has caused - by blurring the distinction between presentation document software and simple word-processor. In a UX ans operational sense lets not go down the same road. Otherwise we may be in a situation where ordinary users are unable to make a distinction between when to shift large files by another means and write-off Bitmessage as an email replacement because they cannot. Educating non CS capable users about such issues is every bit as important as producing decent user and introduction media: definitive videos ans documentation for starters. When Bitmessage is at the sealed design stage, or much closer to it. [..] [..]

Aug 11 12:16

As for Java: Java does produce a lot of boilerplate code that makes for somewhat slow development, that's why I switched to Kotlin, which is a dream to work with, at least for a Java developer. On the other hand, the Java platform provides a plethora of libraries and frameworks that makes up for lost development speed. And the argument of execution speed (which you didn't bring up, but always comes up sooner or later) hasn't been true for a long time. Best regards Chris https://mastodon.dissem.ch/@chrigu

[chan] bitmessage
Aug 11 21:34

Point taken. Java does have just about every bell and whistle you could want. And there are many crypto libs ready to roll. Are you saying that development time for large Java projects is somewhat better than say, ten years ago? I remember people complaining about it and all the boilerplate just to do something simple and I assumed it was still the case.

Aug 12 06:39

Slightly better, but not much. For the most part it's Spring Boot which does have way less boilerplate code than Spring from 10 years ago, bit on a language level it's still about the same. But as I said, Kotlin is a Java developers dream. It integrates almost perfectly with Java code, is null-safe and basically has no boilerplate code. Rewriting Jabit was a matter of maybe 10 or 15 hours, without really knowing Kotlin beforehand, and I fixed a few bugs on the way without even noticing. Of course the speed is also thanks to Jetbrains' great conversion tool which is integrated in IntelliJ IDEA. Best regards Chris

[chan] bitmessage
Aug 13 10:45

ice cream, pizza, puppies. Take a breath in......and now out........now go fuck off.

[chan] bitmessage

Subject Last Count
suicide.note Dec 18 15:59 2
running the 800+ chan super mammoth without "secret chans" ? Dec 18 09:56 1
"publish some code or papers" (800+ mammoth) Dec 18 09:50 1
Penultimate chanlist - 975 chans Dec 18 09:09 6
questionable attitude Dec 18 03:52 23
BM Corporation Dec 18 02:57 6
Вестник дикого ЗАПАДла Dec 18 02:56 1
IIO2Q76P Dec 17 21:47 1
KQMH76VX Dec 17 20:37 1
Feature request Dec 17 19:23 16
New bitmessage readme Dec 17 19:19 2
clean up pyBM github landing page, please Dec 17 19:16 15
walrus - a picture poster for BM Dec 17 15:34 1
mass extinction of BM users Dec 17 02:40 8
zeromail QUESTION Dec 16 23:01 16
bitmessage BM-2cWy7cvHoq3f1rYMerRJp8PT653jjSuEdY Dec 16 20:21 1
I cannot be bought , bullied , reasoned or negotiated with Dec 16 16:45 1
clean up pyBM github landing page, please Dec 16 13:19 1
custom onion address Dec 16 12:11 17
chanlist : 820 chans - the mega mammoth Dec 16 11:14 18
tor release candidate makes hidden services more responsive Dec 16 10:42 1
fuck me I have 80 connections Dec 16 09:15 4
BitText lYrDWSsRQO: VAN confirmation Dec 15 22:48 2
launch torIRC straight from a BM Dec 15 18:32 2
force zeronet trough tor only? Dec 15 15:37 22
BitText Error Dec 15 13:38 2
BitText ADD confirmation Dec 15 13:30 1
cultists on the linux forums browbeat them into sticking to linux Dec 15 12:56 10
evolution - RNA world hypothesis Dec 15 07:24 1
please post your onion and uptime in UTC London time in this list Dec 14 16:43 2
torIRC QUESTION Dec 14 12:40 3
the green light Dec 14 00:43 21
Safe chat software? Dec 13 23:07 18
torIRC 2.33 Dec 13 11:02 2
anyone uses Nyx for tor ? Dec 12 15:22 1
torIRC TBB-9150 version via port 11009 as always Dec 12 15:16 2
update torIRC , TBB-9150 version via port 1801 instead of 11009 Dec 12 09:28 1
torIRC , TBB-9150 version via port 1801 instead of 11009 Dec 12 09:14 1
torIRC latest - TBB-9150 version via port 1801 instead of 11009 Dec 12 09:13 7
bm as hidden service with stem Dec 12 03:11 10
sent via API : torIRC9050.py Dec 11 12:59 1
run bm in cloud: https://mybinder.org Dec 11 09:12 6
BitText XHKhFPCDzj: ultimate bitmessage forum Dec 11 03:10 1
BitText LIST Dec 11 02:39 1
Jupyter BM notebook with py2.7 Dec 11 00:34 1
firewall vs. pyBM green mode Dec 10 09:33 8
run bm in cloud Dec 9 19:13 6
The Stallman Tax Dec 9 14:47 1
using eclipse for pyBM & github Dec 7 15:28 7
BM w/ GUI : Jupyter BM notebook Dec 7 15:19 10
BM in python3? Dec 6 17:52 8
Listen for incoming on Tor hidden service Dec 6 15:43 12
why are all the channels blank Dec 6 06:24 4
Feature idea Dec 5 23:53 5
include the mammoth into pyBM source code Dec 5 11:18 1
include the mammoth into pyBM source code Dec 5 11:15 2
running the 800+ chan super mammoth Dec 5 10:20 32
the myth of the "secret chans" on BM Dec 4 20:23 1
[chan] DevTalk Dec 4 20:13 6
Hacking Bitmessage Dec 4 19:11 3
The complete full mammoth "keys.dat" file - replace your KEYS.DAT in pyBitMessage with this 800+ chan text file -- run the super mammoth ! Dec 4 16:23 2
clean up pyBM github landing page Dec 3 20:28 14
audit - squash this lil bug Dec 3 20:04 1
Error Dec 3 18:47 1
34C3 Dec 3 18:44 3
48 Dirty Little Secrets Cryptographers Don't Want You to Know Dec 3 17:50 1
mailchuck = OK ; onionmail = problematic Dec 3 16:27 6
mammoth chan list .py Dec 3 06:53 3
SUPER MAMMOTH -- 806 unique BM chans in one keys.dat file Dec 3 01:39 1
questionable attitude web.archive.org/web/20171202215905/http://bitmessage.mybb.im/viewtopic.php?id=30%23p106 Dec 2 22:42 1
ACK : Persistence via Dead Letter drop clearnet access w/Op separation Dec 2 12:42 1
OMEGA release 39 is available for download Dec 2 05:15 1
I get no reply from mailchuck upon registration -- fixed ! all working again. Dec 2 02:13 4
beamstat.com is fucking fast to serve broadcasts Dec 2 01:47 1
27'000 users who use OnionMail - more than BM ? sure ... Dec 1 10:40 1
beamstat.com is fucking slow to serve broadcasts Dec 1 10:34 4
Patch 4 Dec 1 10:31 5
crowdfunding : whack Trump Dec 1 10:31 11
27'000 users who use OnionMail - more than BM ? Dec 1 07:16 10
dotsendack =True *** stealth mode Dec 1 07:16 5
Pubkey request Dec 1 07:15 6
NEW ! subscribe to this pml : BM-NB4TuMJmrHeo1p1FsfuMCrkZBUPGLjnq Dec 1 07:15 7
Bitmessage feature request for timing attack mitigation Dec 1 07:15 14
How to disable ack packets Nov 30 13:07 36
Easter egg Nov 30 12:13 2
I get no reply from mailchuck upon registration Nov 30 11:40 8
easy mailer , just add MX line in DNS Nov 30 10:59 2
Bitmessage to Shell Nov 30 05:01 4
Patch 3 Nov 30 04:36 1
Patch 2 Nov 30 04:32 1
Patch Nov 30 04:18 1
Long delay making connections Nov 29 09:44 25
onion mail Nov 29 00:56 1
Flatpak Linux Distribution for Bitmessage Nov 28 20:19 1
sue corporations like stman sues postal services Nov 28 13:11 1
backbone member Nov 28 13:10 9
pyBM light load even on old laptops Nov 28 07:37 2
BM now with ding dong Nov 27 03:05 3