phone

    • chevron_right

      Monal IM: Burned by an old typo

      Anu • news.movim.eu / PlanetJabber • 22 February, 2020

    At some point a long time ago while writing the OMEMO code I entered in the device features. While returning the features that Monal supported, I returned eu.siacs.conversations.axolotl.devicelist instead of eu.siacs.conversations.axolotl.devicelist+notify . The missing +notify meant I didn’t get notifications when the device list changed causing all sort of havoc. Thankfully its been fixed and there is a new Mac beta up as well as a TestFlight build. Thanks everyone for all of your testing, its been gradual but few things shine a light on bugs like testing.

    • wifi_tethering open_in_new

      This post is public

      monal.im /blog/burned-by-an-old-typo/

    • chevron_right

      Monal IM: Mac Catalyst delayed in the Appstore.. it’s blocking the keychain

      Anu • news.movim.eu / PlanetJabber • 21 February, 2020

    It seems that the mac app store is currently blocking the use of the keychain as a non public api. It’s clearly a bug because this has worked fine for a decade and until yesterday there were no issues. Until they resolve this, i can’t upload new catalyst builds — including the one intended for the appstore

    ITMS-90338: Non-public API usage – The app references non-public symbols in Contents/Frameworks/SAMKeychain.framework/Versions/A/SAMKeychain: _SecItemAdd, _SecItemCopyMatching, _SecItemDelete, _SecItemUpdate, _kSecAttrAccessible, _kSecAttrAccount, _kSecAttrLabel, _kSecAttrService, _kSecAttrSynchronizableAny, _kSecClass, _kSecMatchLimit, _kSecMatchLimitAll, _kSecMatchLimitOne, _kSecReturnAttributes, _kSecReturnData, _kSecValueData,

    • wifi_tethering open_in_new

      This post is public

      monal.im /blog/mac-catalyst-delayed-in-the-appstore-its-blocking-the-keychain/

    • chevron_right

      Monal IM: Removing Google talk

      Anu • news.movim.eu / PlanetJabber • 20 February, 2020

    I am planning to remove Google talk support from 4.4 onwards for Mac and iOS. Its an sad milestone because Google talk was why I made Monal in 2008. However, given google themselves have deprecated it twice and even its replacement google chat has been deprecated, it seems increasingly less important. Additionally, the fact that it does not support any modern xmpp specs and doesn’t work with push means it is barely usable in current versions of Monal. I don’t track user stats but I suspect everyone who used to use this for google has moved on to other clients or slack.

    If you *REALLY* need Google talk the legacy mac client will still be around for a little bit.

    • wifi_tethering open_in_new

      This post is public

      monal.im /blog/removing-google-talk/

    • chevron_right

      Monal IM: New Mac and iOS beta bre updated

      Anu • news.movim.eu / PlanetJabber • 20 February, 2020

    There was a bug in last nights iOS and Mac builds that caused it to crash on group chats. I have updated both clients now. I have also linked the old Monal-OSX.zip file to the catalyst version. Catalyst is the mac client now. This should allow brew users to get it as well. Unlike the old Monal for mac, the new one is sandboxed, hardened runtime and notarized.

    • wifi_tethering open_in_new

      This post is public

      monal.im /blog/new-mac-and-ios-beta-bre-updated/

    • chevron_right

      Monal IM: XMPP is weird

      Anu • news.movim.eu / PlanetJabber • 20 February, 2020

    There are many weird things about xmpp. The contact approval system and the need to approve a contact to send encrypted messages is probably one of the best examples. A lot of OMEMO issues can probably be traced to your contacts subscription either being to, from or none. Those words alone don’t make much sense so I have added some “debugging” text for users in contact details.

    • wifi_tethering open_in_new

      This post is public

      monal.im /blog/xmpp-is-weird/

    • chevron_right

      Monal IM: Monal 4.3 is coming out in about a week (even in France)

      Anu • news.movim.eu / PlanetJabber • 13 February, 2020

    Monal 4.3 is going to be a huge update the iOS and Mac UI. It is feature complete and has been in testing for a few weeks. I expect to release it next week. When it comes out though, I will have switched to Apple’s GCM library this will also allow me to release in France. The change in libraries will prevent OMEMO from working with some other clients. Clients that send with a 16 byte iv will not be able to send to Monal anymore. Client that can’t accept the 12 byte iv will not be able to accept message from Monal anymore.

    • wifi_tethering open_in_new

      This post is public

      monal.im /blog/monal-4-3-is-coming-out-in-about-a-week-even-in-france/

    • chevron_right

      Ignite Realtime Blog: Openfire 4.5.0 is Released

      @akrherz daryl herzmann • news.movim.eu / PlanetJabber • 10 January, 2020 • 2 minutes

    @akrherz wrote:

    Happy 2020 everyone! The Ignite Realtime Community is thrilled to announce the promotion of Openfire version 4.5.0. This is a feature and bug fix release with a number of Jira issues closed denoted in the changelog . We are thankful for the issues found by community users during a beta testing period of this release. If you find any problems with this release, please let us know in the community forums or drop by our web support groupchat .

    So what’s in this new release? First, you will notice a new login screen on the administration console like so:
    ss

    Manassé Ngudia did the excellent work to move the admin console to use the Bootstrap library for a responsive design. With this foundation, we hope to move more parts of the admin console to a responsive design and thus render more favorably on mobile.

    @guus and @gdt did heroic work, as always, to squash a number of bugs and greatly improve LDAP support. If you have had trouble in the past with Openfire + LDAP, please consider testing this release out and let us know how it goes!

    You can find Openfire release artifacts on the download page and with the following sha1sum s:

    b4d8d77701d6524a4d26c4e8a6cba82f6e5d9d68  openfire-4.5.0-1.i686.rpm01b583d27ea8d644376588e7226be0ad93d8d728  openfire-4.5.0-1.noarch.rpm6bc54cf3de57e7359143ab8f6ff015b191c4e898  openfire-4.5.0-1.x86_64.rpm4e1bd74d0140178936dbb39f076b9817d2bfe945  openfire_4.5.0_all.deb36a0ee7d4cc44d18524c5540bcba5af6e133fcc2  openfire_4_5_0_bundledJRE.exe959441b2cd18b62861e14d4fea705ae57f8f6361  openfire_4_5_0_bundledJRE_x64.exefe9cebfb37eb126416aed3438b9aa28b796a987c  openfire_4_5_0.dmgc4c900dbb4607a1f1eed8cce2e18fa4b2509bf52  openfire_4_5_0.exec4cf10939a9b573c3eee4637a7b8f38f3b4305b9  openfire_4_5_0.tar.gzceeb49bd51e6ae555e3dadf193b1ed2da811f959  openfire_4_5_0_x64.exeda0050d284089331241ca023d40d2c382e37bfd9  openfire_4_5_0.zipdf4e0905ab52b0b1d4fea344ee4efe0ed119674d  openfire_src_4_5_0.tar.gz85ee3714a05db13e1ad2967c6e6fde0c1d52269f  openfire_src_4_5_0.zip

    With regards to future development plans, the master github branch has been marched toward a version 4.6.0 snapshot with a 4.5 branch created to signify an intention to produce followup bug fix releases of version 4.5.0 released today. At this time, there is no plan for a future 4.4.x series release.

    We always could use more folks pitching in and helping out with documentation, testing and development! Thanks for your interest and usage of Openfire!

    Posts: 1

    Participants: 1

    Read full topic

    • chevron_right

      ProcessOne: Towards Lean Computing: Integrating Energy Consumption in Application Design

      Mickaël Rémond • news.movim.eu / PlanetJabber • 10 January, 2020 • 4 minutes

    In the quest for better energy efficiency, the applications themselves are often overlooked. Our industry likes to pretend that all technologies are equivalent and has forgotten that the choice of programming languages, frameworks and architecture have a major impact on energy consumption.

    The observation

    Today we are all aware of the environmental impact of the objects, tools, devices we use. We all know that when we use our car, this usage will have a “carbon” impact. A whole industry is working to reduce the energy impact of the appliances we use. Our environmental awareness is leading us to moderate our use, by using appliances that consume less energy, or depend on a mix with more renewable energies. Finally, we even consider alternatives, such as replacing the car with a public transit, or cycling.

    Taking into account the carbon footprint of our actions is more evident in the transport field. In the IT sector, we are only at the beginning, but our massive use of computing power and data turned the Internet into a major energy drain.

    In 2017, Greenpeace considered Internet electric consumption to represent 7% of the world’s electricity consumption. The report is based on 2016 data. It is very likely that we are well beyond that point today. The growth in data traffic exceeds the advances in energy efficiency of network equipment. The “Low Tech Magazine” explains the problem very well: About Low Tech Magazine .

    In other words, it means that all the world’s IT departments, phones, data centers, etc. emit more carbon than air transport, for example.

    Keeping Internet infrastructure and usage under control

    The awareness is growing, but the solutions being explored focus on only two lines of action, forgetting a third but fundamental one.

    The first line of action on the energy consumption of the Internet is geared at infrastructure . The energy consumption of the infrastructure is dealt with at two levels:

    1. Reducing energy consumption in data centers. One example is OVH’s work on hydraulic cooling systems , replacing both the fans in the servers and the air conditioning in the data centres.
    2. The source of electric supply. An effort is being made by large groups such as Facebook, or Google to buy renewable electricity, i.e. electricity produced from renewable energy.

    The second line of action to reduce the energy impact is usage limitation . From a user’s point of view, we have all seen awareness-raising campaigns recommending that people decrease their use of e-mail or even reduce the resolution of videos consumed to save bandwidth and electricity. This is an important step forward, but we must now go beyond it, to reduce the energy impact of everyday use.

    Designing lightweight and efficient applications

    Cloud computing has changed the way applications are designed. It’s an industry, with most of the major players now being business infrastructure providers. Cloud players offer increasingly sophisticated services and have simplified the use of online capabilities.

    So much so that it is common today to design architecture that can scale-up automatically. It is even commonly accepted that human time is the most expensive and valuable resource. Consequently, it is better to put more and bigger servers to run one’s service than to spend time optimizing it. The environmental cost of time-to-market pressure is real. Cloud computing has made it too easy to leverage ever-increasing resources.

    In this race to consume more and more, our industry has forgotten that this attitude is a major contributor to greenhouse gas emissions. This attitude is the IT equivalent of intensive agriculture. We need a new approach.

    A third line of action: Measure and optimize

    Another line of action to reduce the impact of the Internet on the planet is to rediscover optimization know-how, to be well aware of the impact of architecture decisions on our applications.

    Many parameters have to be taken into account and can have a real impact on the environment:

    1. The type of architecture . Some architectures are more efficient than others. Intensive use of middleware and microservices can have a negative impact on the energy balance of a service.
    2. The panel of technologies . We have to be realistic, some technologies are convenient for development, but very energy consuming. For example, at ProcessOne, we have taken over the management of a messaging service on our infrastructure. The application was previously running on 30 servers. We now operate it on 4 servers of the same size. The choice of implementation technology makes a huge difference (i.e. Erlang, Elixir, Go).
    3. The set of features . Big data , the massive mining of data, is a great promise of wealth creation. However, the business case does not not always exist and storing and processing huge volumes of data just in case you may need it doesn’t seem rational. You have to think ahead about what you want to analyze and why. This approach is not really compatible with the General Data Protection Regulations (GDPR).

    Conclusion

    At the end of the day, companies have an important responsibility in the energy consumption of the Internet. They cannot be done with it by just shifting the burden to infrastructure providers and users. They have to take their share of the responsibility.

    If you want to know how to address the problem, ProcessOne can certainly help you, by working on the whole process, and by helping you benchmark your application to monitor its performance.

    So, are you ready to tackle the challenge with me and reducing the energy footprint of your applications?

    • wifi_tethering open_in_new

      This post is public

      blog.process-one.net /towards-lean-computing-integrating-energy-consumption-in-application-design/

    • chevron_right

      Monal IM: Mac 2.5 beta 1

      Anu • news.movim.eu / PlanetJabber • 16 December, 2019

    This is a new Mac beta available. This is the regular non catalyst version. This brings over all of the iOS fixes that has been in testing for the past couple of weeks. I am hoping for a quick turn around and testing cycle for the UI here to get to production soon.

    • wifi_tethering open_in_new

      This post is public

      monal.im /blog/mac-2-5-beta-1/