elective-stereophonic
elective-stereophonic
NRS v1.6.2
Please login or register.

Login with username, password and session length
Advanced search  

News:

Latest Stable Nxt Client: Nxt 1.12.2

Pages: 1 ... 4 5 [6] 7 8 ... 18  All

Author Topic: NRS v1.6.2  (Read 90663 times)

yassin54

  • Hero Member
  • *****
  • Karma: +240/-14
  • Offline Offline
  • Posts: 2503
  • I am Homer, Sorry my english is Bad!!
    • View Profile
Re: NRS v1.6.2
« Reply #100 on: November 06, 2015, 02:43:25 pm »

Jean-Luc are you here?  :-\
I think need to vote for crisis  ;D ;D
« Last Edit: November 06, 2015, 02:45:28 pm by yassin54 »
Logged

youyou

  • Sr. Member
  • ****
  • Karma: +44/-46
  • Offline Offline
  • Posts: 472
    • View Profile
Re: NRS v1.6.2
« Reply #101 on: November 06, 2015, 02:48:08 pm »

agree with the vote stuff: the devs are important but in case of crisis the decision should go to the community.
Logged

Riker

  • Core Dev
  • Hero Member
  • *****
  • Karma: +440/-42
  • Offline Offline
  • Posts: 1796
    • View Profile
Re: NRS v1.6.2
« Reply #102 on: November 06, 2015, 02:51:42 pm »

Folks, I'd like to say a few words, I've been working on the NXT core from August last year together with jean-luc, and this Sunday I accepted the nomination of a project manager. As a representative of the core developers I'd like to say there is nothing we want more than making it easy for businesses use the NXT platform.
I've been in the software business for ages and breaking APIs is never a good thing but we have to keep things in proportion.
As a project manager I would strive to keep API stability as much as possible in the future and if an API change is absolutely mandatory I would make sure this is properly communicated and documented.
Logged
NXT Core Dev
Account: NXT-HBFW-X8TE-WXPW-DZFAG
Public Key: D8311651 Key fingerprint: 0560 443B 035C EE08 0EC0  D2DD 275E 94A7 D831 1651

Cassius

  • Hero Member
  • *****
  • Karma: +207/-18
  • Offline Offline
  • Posts: 2459
  • Rather be a pirate than join the navy
    • View Profile
Re: NRS v1.6.2
« Reply #103 on: November 06, 2015, 02:53:25 pm »

Folks, I'd like to say a few words, I've been working on the NXT core from August last year together with jean-luc, and this Sunday I accepted the nomination of a project manager. As a representative of the core developers I'd like to say there is nothing we want more than making it easy for businesses use the NXT platform.
I've been in the software business for ages and breaking APIs is never a good thing but we have to keep things in proportion.
As a project manager I would strive to keep API stability as much as possible in the future and if an API change is absolutely mandatory I would make sure this is properly communicated and documented.

Thanks Riker. It does seem like this happened very fast. Are there ways of smoothing the transition? (Bear in mind in any answer that I'm not a dev.)
Logged
I head up content for BitScan, crypto business hub.

Daedelus

  • Hero Member
  • *****
  • Karma: +230/-12
  • Offline Offline
  • Posts: 3280
    • View Profile
Re: NRS v1.6.2
« Reply #104 on: November 06, 2015, 02:55:40 pm »

Yes, I have heard the suggestion about versioned APIs, but we don't have the development resources to maintain such versioning, and it would be an overkill for a change like the include parameter defaults. Even if we did have versioned APIs, for how many versions back would you expect that they should be maintained? If for two versions, this is the same as what you get by allowing both 1.5 and 1.6 to coexist on the network until the next hard fork, if you need the old version stay with 1.5.

So it seems the community needs to either:
  • find more core development resource for versioning/more communication, or
  • none core devs stay on 1.5 for now and migrate over a few weeks/months, or
  • a little of both? Teams are small, no one is made of money and there are only 24 hours in a day.
Logged
NXT: NXT-4CS7-S4N5-PTH5-A8R2Q

jl777

  • Hero Member
  • *****
  • Karma: +718/-123
  • Offline Offline
  • Posts: 6170
    • View Profile
Re: NRS v1.6.2
« Reply #105 on: November 06, 2015, 02:57:33 pm »

Folks, I'd like to say a few words, I've been working on the NXT core from August last year together with jean-luc, and this Sunday I accepted the nomination of a project manager. As a representative of the core developers I'd like to say there is nothing we want more than making it easy for businesses use the NXT platform.
I've been in the software business for ages and breaking APIs is never a good thing but we have to keep things in proportion.
As a project manager I would strive to keep API stability as much as possible in the future and if an API change is absolutely mandatory I would make sure this is properly communicated and documented.
Breaking dozens of existing API is not striving very hard. Promises for backward compatibility have been made and broken already.

Promises for striving for backward compatibility is useless.

Imagine 10,000+ SuperNET users and EVERY install becomes broken with a new NXT release. That would kill SuperNET and I do not like to do suicide

James
Logged
There are over 1000 people in SuperNET slack! http://slackinvite.supernet.org/ automatically sends you an invite

I am just a simple C programmer

Damelon

  • Hero Member
  • *****
  • Karma: +792/-54
  • Offline Offline
  • Posts: 2314
    • View Profile
    • Nxt Inside
Re: NRS v1.6.2
« Reply #106 on: November 06, 2015, 03:01:36 pm »



Folks, I'd like to say a few words, I've been working on the NXT core from August last year together with jean-luc, and this Sunday I accepted the nomination of a project manager. As a representative of the core developers I'd like to say there is nothing we want more than making it easy for businesses use the NXT platform.
I've been in the software business for ages and breaking APIs is never a good thing but we have to keep things in proportion.
As a project manager I would strive to keep API stability as much as possible in the future and if an API change is absolutely mandatory I would make sure this is properly communicated and documented.
Breaking dozens of existing API is not striving very hard. Promises for backward compatibility have been made and broken already.

Promises for striving for backward compatibility is useless.

Imagine 10,000+ SuperNET users and EVERY install becomes broken with a new NXT release. That would kill SuperNET and I do not like to do suicide

James

Rather an unfair assessment, as he only started FOUR days ago in this function.

ChuckOne did this before and after he went we are lucky to have someone again.

Regardless of the feelings over this, laying this at Rikers feet is unfair.

Verstuurd vanaf mijn SM-G901F met Tapatalk

Logged
Member of the Nxt Foundation | Donations: NXT-D6K7-MLY6-98FM-FLL5T
Join Nxt Slack! https://nxtchat.herokuapp.com/
Founder of Blockchain Workspace | Personal Site & Blog

Riker

  • Core Dev
  • Hero Member
  • *****
  • Karma: +440/-42
  • Offline Offline
  • Posts: 1796
    • View Profile
Re: NRS v1.6.2
« Reply #107 on: November 06, 2015, 03:04:26 pm »

Folks, I'd like to say a few words, I've been working on the NXT core from August last year together with jean-luc, and this Sunday I accepted the nomination of a project manager. As a representative of the core developers I'd like to say there is nothing we want more than making it easy for businesses use the NXT platform.
I've been in the software business for ages and breaking APIs is never a good thing but we have to keep things in proportion.
As a project manager I would strive to keep API stability as much as possible in the future and if an API change is absolutely mandatory I would make sure this is properly communicated and documented.
Breaking dozens of existing API is not striving very hard. Promises for backward compatibility have been made and broken already.

Promises for striving for backward compatibility is useless.

Imagine 10,000+ SuperNET users and EVERY install becomes broken with a new NXT release. That would kill SuperNET and I do not like to do suicide

James

James, we will definitely not break SuperNET again. I do recommend that every SuperNET release which is based on a new NXT release would be designated as a beta release until properly tested.
« Last Edit: November 06, 2015, 03:10:16 pm by Riker »
Logged
NXT Core Dev
Account: NXT-HBFW-X8TE-WXPW-DZFAG
Public Key: D8311651 Key fingerprint: 0560 443B 035C EE08 0EC0  D2DD 275E 94A7 D831 1651

EvilDave

  • Hero Member
  • *****
  • Karma: +341/-40
  • Offline Offline
  • Posts: 1789
    • View Profile
    • NXT Foundation
Re: NRS v1.6.2
« Reply #108 on: November 06, 2015, 03:11:00 pm »

OK...this needs to be sorted out now, or we can all look forward to a very shitty winter.

Simply put: SuperNET and NXT are so linked with each other that a SuperNET exit from Nxt will probably kill both projects, or at least lose a lot of what we have been working for over the last two years.
I do not want this to happen, and I'm pretty sure that no-one else in the community wants this to happen.

There is no simple solution, but there are ways to ensure that backwards compatibilty is maintained.

I suggest 2 basic ideas:

1: Communication with core devs needs to be improved. Lyaffe taking on the project manager role (as of a week ago) is a step towards this.
A mailing list is also being set up to allow external devs better communication with core (and vice versa).
Ideally, I'd like to see at least a one month window for communincation/discussion of any changes before release of a new NRS version.

2: So we should also slow down the pace of NRS releases, and give people more time to get any changes in place before upgrading to a new version.
I suggest we allow both 1.5.15 and 1.6.2 to co-exist for a while, if that is practical, while we figure this out.

Like it says on the Slack splashscreen: we are all in this together.

Logged
Nulli Dei, nulli Reges, solum NXT
NXT Donations: NXT-BNZB-9V8M-XRPW-3S3WD
We will ride eternal, shiny and chrome!

bcdev

  • Hero Member
  • *****
  • Karma: +162/-22
  • Offline Offline
  • Posts: 666
    • View Profile
Re: NRS v1.6.2
« Reply #109 on: November 06, 2015, 03:20:13 pm »

Quote from: Linus Torvalds
Mauro, SHUT THE FUCK UP!

It's a bug alright - in the kernel. How long have you been a
maintainer? And you *still* haven't learnt the first rule of kernel
maintenance?

If a change results in user programs breaking, it's a bug in the
kernel. We never EVER blame the user programs.
How hard can this be to
understand?

To make matters worse, commit f0ed2ce840b3 is clearly total and utter
CRAP even if it didn't break applications. ENOENT is not a valid error
return from an ioctl. Never has been, never will be. ENOENT means "No
such file and directory", and is for path operations. ioctl's are done
on files that have already been opened, there's no way in hell that
ENOENT would ever be valid.

> So, on a first glance, this doesn't sound like a regression,
> but, instead, it looks tha pulseaudio/tumbleweed has some serious
> bugs and/or regressions.

Shut up, Mauro. And I don't _ever_ want to hear that kind of obvious
garbage and idiocy from a kernel maintainer again. Seriously.

I'd wait for Rafael's patch to go through you, but I have another
error report in my mailbox of all KDE media applications being broken
by v3.8-rc1, and I bet it's the same kernel bug. And you've shown
yourself to not be competent in this issue, so I'll apply it directly
and immediately myself.

WE DO NOT BREAK USERSPACE!

Seriously. How hard is this rule to understand? We particularly don't
break user space with TOTAL CRAP. I'm angry, because your whole email
was so _horribly_ wrong, and the patch that broke things was so
obviously crap. The whole patch is incredibly broken shit. It adds an
insane error code (ENOENT), and then because it's so insane, it adds a
few places to fix it up ("ret == -ENOENT ? -EINVAL : ret").

The fact that you then try to make *excuses* for breaking user space,
and blaming some external program that *used* to work, is just
shameful. It's not how we work.


Fix your f*cking "compliance tool", because it is obviously broken.
And fix your approach to kernel programming.

               Linus
https://lkml.org/lkml/2012/12/23/75
Logged

yassin54

  • Hero Member
  • *****
  • Karma: +240/-14
  • Offline Offline
  • Posts: 2503
  • I am Homer, Sorry my english is Bad!!
    • View Profile
Re: NRS v1.6.2
« Reply #110 on: November 06, 2015, 03:20:39 pm »


1: Communication with core devs needs to be improved. Lyaffe taking on the project manager role (as of a week ago) is a step towards this.
A mailing list is also being set up to allow external devs better communication with core (and vice versa).
Ideally, I'd like to see at least a one month window for communincation/discussion of any changes before release of a new NRS version.

2: So we should also slow down the pace of NRS releases, and give people more time to get any changes in place before upgrading to a new version.
I suggest we allow both 1.5.15 and 1.6.2 to co-exist for a while, if that is practical, while we figure this out.

Like it says on the Slack splashscreen: we are all in this together.
i am totaly agree for all and this phrase red

Ludom

  • Hero Member
  • *****
  • Karma: +197/-15
  • Offline Offline
  • Posts: 1733
    • View Profile
    • Plaisir & Valeur d'histoire
Re: NRS v1.6.2
« Reply #111 on: November 06, 2015, 03:23:50 pm »

As I understand, we need more CORE developers. We can fund it like Tennessee.
Logged
Support us to publish "The first book about Nxt"

Tosch110

  • Hero Member
  • *****
  • Karma: +211/-18
  • Offline Offline
  • Posts: 2365
    • View Profile
Re: NRS v1.6.2
« Reply #112 on: November 06, 2015, 03:24:15 pm »

Folks, I'd like to say a few words, I've been working on the NXT core from August last year together with jean-luc, and this Sunday I accepted the nomination of a project manager. As a representative of the core developers I'd like to say there is nothing we want more than making it easy for businesses use the NXT platform.
I've been in the software business for ages and breaking APIs is never a good thing but we have to keep things in proportion.
As a project manager I would strive to keep API stability as much as possible in the future and if an API change is absolutely mandatory I would make sure this is properly communicated and documented.
Breaking dozens of existing API is not striving very hard. Promises for backward compatibility have been made and broken already.

Promises for striving for backward compatibility is useless.

Imagine 10,000+ SuperNET users and EVERY install becomes broken with a new NXT release. That would kill SuperNET and I do not like to do suicide

James

James, we will definitely not break SuperNET again. I do recommend that every SuperNET release which is based on a new NXT release would be designated as a beta release until properly tested.

The problem is that SuperNET apps are mostly designed to use Jay. And what Jay does is that it connects to random public nodes (to increase decentralization and the user would not have to install Nxt locally and download the blockchain. Even though, we still open the possibility and recommend the user to install Nxt). What Jay will do most of the time when a user runs SuperNET Lite for example is connecting to strong nodes in the network. And these strong and reliable nodes are expected to run the newest stable version. So once this newest stable version (like 1.6.2) breaks the existing API, all SuperNET apps will not function in this case.

There would be an option to hardcode Nxt version compatibility within the SuperNET app. This would create new problems as the older the SuperNET app, the lower the hardcoded Nxt version and at some point it is most likely stops to work because nobody runs a public node with an old Nxt version. So as long as Nxt breaks the API, we have to create a new SuperNET version and every other app which uses Jay or a public node approach (which is a huge strength of Nxt) is likely to be doomed in the long run.

I would also like to emphasize that breaking the API (or hardfork) creates a point of centralization where people are forced to use the new Nxt version. If they do not want to, they cannot connect to the network with an old version because it is network incompatible.
And then, Nxt changes the License, forces people to new upgrades, makes them dependend to stay always in touch with newest Nxt updates and versions because if not the App is most likely to be incompatible with the network after a few months.

So I am asking, please make it either easy to follow new breakes (in advance) or maintain the API and hardforkes so they are backwards compatible. In this case setting the default value to true, so it returns the same information as before. In case people want to speed up their calls, they can not return those values and have faster apps... but breaking everything and take the approach to make things fast before stable is not the right solution imo.

jl777

  • Hero Member
  • *****
  • Karma: +718/-123
  • Offline Offline
  • Posts: 6170
    • View Profile
Re: NRS v1.6.2
« Reply #113 on: November 06, 2015, 03:24:22 pm »

OK...this needs to be sorted out now, or we can all look forward to a very shitty winter.

Simply put: SuperNET and NXT are so linked with each other that a SuperNET exit from Nxt will probably kill both projects, or at least lose a lot of what we have been working for over the last two years.
I do not want this to happen, and I'm pretty sure that no-one else in the community wants this to happen.

There is no simple solution, but there are ways to ensure that backwards compatibilty is maintained.

I suggest 2 basic ideas:

1: Communication with core devs needs to be improved. Lyaffe taking on the project manager role (as of a week ago) is a step towards this.
A mailing list is also being set up to allow external devs better communication with core (and vice versa).
Ideally, I'd like to see at least a one month window for communincation/discussion of any changes before release of a new NRS version.

2: So we should also slow down the pace of NRS releases, and give people more time to get any changes in place before upgrading to a new version.
I suggest we allow both 1.5.15 and 1.6.2 to co-exist for a while, if that is practical, while we figure this out.

Like it says on the Slack splashscreen: we are all in this together.
1. What good is "communication" when ALL my concerns are ignored.
2. This breaking of API was done intentionally and the defaults for dozens of API calls REVERSED from what is already there. The fact this is treated as a "feature" and not a DOA bug boggles my mind

James

P.S. SuperNET will incur a delay to remove its NXT dependency, but it will certainly not die from not depending on NXT, rather my assessment is that it is more likely to die if it depends on NXT that is guaranteed to not be backward compatible
Logged
There are over 1000 people in SuperNET slack! http://slackinvite.supernet.org/ automatically sends you an invite

I am just a simple C programmer

_mr_e

  • Hero Member
  • *****
  • Karma: +88/-18
  • Offline Offline
  • Posts: 956
    • View Profile
Re: NRS v1.6.2
« Reply #114 on: November 06, 2015, 03:25:01 pm »

Perhaps the Nxt community is learning first hand exactly why Bitcoin development moves so slow.... hmm....
Logged

Eth

  • Jr. Member
  • **
  • Karma: +12/-1
  • Offline Offline
  • Posts: 18
    • View Profile
Re: NRS v1.6.2
« Reply #115 on: November 06, 2015, 03:26:03 pm »

Dear @Jean-Luc and @Riker.

I am a member of the superNET core development team, but would like to strip off that title for a few minutes and try to write as a simple NXT user, hopefully keeping 100% objectivity.

First things first, no one here doubt of your performance as coders and enthusiasm as creators, certainly your contribution is priceless for the NXT platform. We all know that.

But.

We shall not forget of the nature of a crypto platform at its core. The decentralization is a (perhaps an utopia but) goal that everyone involved in this scene is familiar with, and look at with hope. Right now, even Bitcoin looks more decentralized, which is saying a lot.
I will not list here personal information, just would like to let you know that management and business development is not a foreign topic for me, and the path you are choosing right now is going to hurt NXT, bad, beyond your imagination.

If you guys use this philosophy, simply no one will use the platform. There is not a single serious enterprise that would do so, and risk all their userbase and the reputation of their brands. What will become of NXT then?

I suggest that you think deeper about this matter and if possible, announce to the community about the decision taken.
There are people that have been fighting for NXT a long time (way more than me, I am relatively new here with just 1 year of experience, even though I have brought MANY investors to NXT ecosystem), so at least do it for the sake of the respect that all that people deserve.

One more thing before i conclude, even when there are intelligent people at the wheel of the coding side (at least with a strong mathematical logic side, no one can deny that), it does not mean that they are good in diplomacy, politics or taking decisions, and at the end of the day, the success or the failure of an platform or organization, (like NXT), depends on having a group of people with different skills (like the latter mentioned) and personalities putting their brains together.
I am conscious that NXT have many good brains around, not making use of them all is a waste.

Regards,

Eth.


Logged

jl777

  • Hero Member
  • *****
  • Karma: +718/-123
  • Offline Offline
  • Posts: 6170
    • View Profile
Re: NRS v1.6.2
« Reply #116 on: November 06, 2015, 03:33:01 pm »

Yes, I have heard the suggestion about versioned APIs, but we don't have the development resources to maintain such versioning, and it would be an overkill for a change like the include parameter defaults. Even if we did have versioned APIs, for how many versions back would you expect that they should be maintained? If for two versions, this is the same as what you get by allowing both 1.5 and 1.6 to coexist on the network until the next hard fork, if you need the old version stay with 1.5.

So it seems the community needs to either:
  • find more core development resource for versioning/more communication, or
  • none core devs stay on 1.5 for now and migrate over a few weeks/months, or
  • a little of both? Teams are small, no one is made of money and there are only 24 hours in a day.
it does not matter how much time is allowed before BREAKING the installed base.
NXT is either a platform with API that can be coded to, or it isnt

Now to put this in nontechnical perspective:

Let us imagine the electric company decides that using 300V will be a lot more efficient than 220V and certainly more efficient than 110V, so it announces in some little read testnet release notes that all sockets will now provide 300V instead of what it used to.

Now all users just have to make some small changes or get new devices and it is all much more efficient.

The 300V "upgrade" is deployed globally and the vast majority of devices just stop working.

But there is a very good technical explanation that explains why this is a good thing.

This is basically what happened. Now how much communication and lead time is needed to switch to 300V electric outlets?

James
Logged
There are over 1000 people in SuperNET slack! http://slackinvite.supernet.org/ automatically sends you an invite

I am just a simple C programmer

superdaveosborne

  • Jr. Member
  • **
  • Karma: +10/-0
  • Offline Offline
  • Posts: 17
    • View Profile
Re: NRS v1.6.2
« Reply #117 on: November 06, 2015, 03:37:05 pm »

I lead configuration management for a multi million dollar system within a large corporation.  I would have been summarily fired over a violation of protocol with a fraction of this impact.

NXT core devs need to learn how to communicate.  This is not your own little science project that you can tweak to your hearts content.  You all simply must discuss changes of this magnitude with the larger development community or NXT has no chance at attracting business customers.  Why would any business choose to use this platform when every release might break backwards compatibility?  They won't.

There really is no counter argument here.  Code should be depricated and removed slowly over time with ample warning and communication.  Not ninja released with no documentation.

Logged

neofelis

  • Hero Member
  • *****
  • Karma: +74/-12
  • Offline Offline
  • Posts: 568
    • View Profile
Help for MAC
« Reply #118 on: November 06, 2015, 03:57:41 pm »

Need help with NXT Wallet for MAC.  I downloaded it off nxt.org but it gets stuck starting up.  I've tried this on both of my desktop computers and have even deleted every nxt file I have to try and clean my system but I still can't get it to load correctly.  Suggestions anybody?

Neofelis
Logged

jl777

  • Hero Member
  • *****
  • Karma: +718/-123
  • Offline Offline
  • Posts: 6170
    • View Profile
Re: Help for MAC
« Reply #119 on: November 06, 2015, 04:00:21 pm »

Need help with NXT Wallet for MAC.  I downloaded it off nxt.org but it gets stuck starting up.  I've tried this on both of my desktop computers and have even deleted every nxt file I have to try and clean my system but I still can't get it to load correctly.  Suggestions anybody?

Neofelis
The Mac wallet used to work, but it has no active development, at least not much. so all the API changes probably killed it.
Logged
There are over 1000 people in SuperNET slack! http://slackinvite.supernet.org/ automatically sends you an invite

I am just a simple C programmer
Pages: 1 ... 4 5 [6] 7 8 ... 18  All
 

elective-stereophonic
elective-stereophonic
assembly
assembly