<DocScrutinizer05>
HiFo wasn't even set up to decide such stuff
<wpwrak>
when has a lack of mandate every stopped an ambitious politician ? ;-)))
<wpwrak>
# s/every/ever/
<DocScrutinizer05>
HiFo was (and is?) a working cashier entity for maemo community. Nobody cares what they decide, since they are not allowed to decide such stuff on their own
<Oksana>
I'm not sure, they probably thought that cashier moving from one country to another does not affect anybody else that much?
<DocScrutinizer05>
wpwrak: please stop trolling with your badmouthing the community volunteers that take care about maemo administration as politicians
<bencoh>
wpwrak: indeed
<DocScrutinizer05>
most are not
<DocScrutinizer05>
those who are are exactly the people that try to hijack maemo now
<DocScrutinizer05>
HiFo was clearly set up to obey instructions of THE maemo community and The council. without any GA or whatever, and it worked. The fact that the e.V. doesn't work in a similar way only shows that it is not designed in a way to ever be a legitimate successor to HiFo
phre4k has joined #neo900
<wpwrak>
DocScrutinizer05: naw, i don't mean to disrespect people who care about their community. but i'm surprised by the amount of politicking going on there. i mean it's like watching "house of cards".
<DocScrutinizer05>
Oksana: it's irrelevant what they thought. HiFo is legally and by own bylaws bound to act in best interest of maemo community and not do own decisions against what community via council tells them shall get done. It' bluntly illegal to pass the assets to a new entity with massively different set of bylaws and organizational structure than HiFo itself has been
<DocScrutinizer05>
the "whatever members" of e.V are exactly what ruins the complete e.V. concept, since everybody can become member
<Oksana>
Only *.maemo.org members are eligible to become e.V. members
<DocScrutinizer05>
an e.V well could have limited own number of members to - say - 12. Then nobody would have been concerned much
<DocScrutinizer05>
aha, says who?
<Oksana>
Bylaws
<Oksana>
Three month membership of *.maemo.org is required
<Oksana>
The inclusion as an active member is executed by the Board upon written or electronic request and requires three months of passive membership. Active members retain all rights and obligations of a passive membership.
<DocScrutinizer05>
still inapt attempt to reimplement a community that already exists
<DocScrutinizer05>
you're creating a 2 classes society
<DocScrutinizer05>
and the justificatiin us "it's needed. And those who don't want to participate in this 2 classes system are the ones to blame, their own fault"
<DocScrutinizer05>
...fication is*
<DocScrutinizer05>
allowing everybody to enter the upper class if only they try hard enough still doesn't justify a 2 classes system
lexik has quit [Remote host closed the connection]
<DocScrutinizer05>
even worse: of course the upper class decides about the rules anybody has to obey/fulfil to be allowed to migrate from plebs to upper class
<DocScrutinizer05>
but nevermind, damage done, since around one year already, the community got killed by that crap already, the damage is done and nobody will ever heal it again
<kerio>
it was a mostly dead community anyway
<kerio>
cssu is basically ran by fmg+merlin+pali
<DocScrutinizer05>
once people of maemo community knew it's about a FOSS project and there's a council they can ask for whatever they want and the council will act in their best interest to make their wishes come true. Now community been told that there's an e.V you need to be member or you are irrelevant for furure of the FOSS project. Guess how many people were _happy_ to hear they are obsolete, and what been their conclusion from learning this
<Oksana>
GA doesn't decide much. GA elects Board and decides about GA's fees. Board obeys rulings of GA and Council, so as long as there is no conflict between them, Board still obeys the Council.
<kerio>
and then merlin releases cssu by himself
<kerio>
merlin >>>>> the e.V. members
<kerio>
wtf is it there for? keeping the maemo copyright?
<kerio>
who gives a fuck, just move the repos to a chinese server
<kerio>
nobody will ever enforce that copyright
<Oksana>
Yes, two-layer society is disorienting. Passive-active also wasn't the most fortunate wording. I wonder, does KDE e.V. invoke the same wtf reaction in KDE community? https://ev.kde.org/
<DocScrutinizer05>
Oksana: read the german e.V laws and maybe this particular e.V's bylaws. The GA decides *everything*
<DocScrutinizer05>
and maemo != KDE
<DocScrutinizer05>
and will neither be KDE nor any fsckng ADAC or whatever that guy thinks was the appropriate *new* orginazational structure of maemo
<DocScrutinizer05>
ever
<DocScrutinizer05>
there's one maemo community and the e.V devided and killed it
<kerio>
DocScrutinizer05: i bet you a neo900 that the maemo.org certs will expire
<kerio>
and nobody will replace them
<DocScrutinizer05>
when there's always been a 2 or 3 or 49 classes society in KDE doesn't mean that's the right thing for maemo
<kerio>
kde can afford to have multiple classes
<kerio>
maemo could only have 49 classes if you put one person per class
<DocScrutinizer05>
yeah, and the the remaining 6000 who execute their right to stay passive into the 50th (lowest) class
<DocScrutinizer05>
which is the whole point in this dilemma
<DocScrutinizer05>
the vocal ones think they *are* the entire community
<kerio>
the people in the board
<kerio>
do they have a scratchbox install?
<DocScrutinizer05>
who cares?
<Oksana>
GA can: elect Board, appoint honorary members, decide on the association rules, decide upon exclusion of a member from GA, remove a member from Board, regulate GA fees. Changes to the articles of association by the General Assembly require at least two thirds of all valid votes cast to support the motion. Changes to the articles of association by the Board of Directors requires a unanimous vote.
<DocScrutinizer05>
board is to check account balances
<kerio>
so the board can be substituted by a perl script?
<DocScrutinizer05>
basically yes
<DocScrutinizer05>
Oksana: see?
<Oksana>
Are all legal representation duties of Board limited to checking account balances?
<DocScrutinizer05>
what I told ya: GA decides *everything*, and they decide upon those who do the dicisions the GA doesn't do by themselves
<DocScrutinizer05>
Oksana: the whole dang entity is meant to only do account balance checking, *nothing else*
<DocScrutinizer05>
for anything else, we got a council
<DocScrutinizer05>
and a community
<Oksana>
Board and Council are authorised to enact internal regulations for themselves. Bylaws enacted by Board are governed by Board internal regulations. Bylaws enacted by Council are governed by Association Rules.
<DocScrutinizer05>
you don't need to quote random excerpts of the e.V bylaws here
<DocScrutinizer05>
I know how a german e.V works, I've seen and participated in quite a few already, even during foundation of them. Unlike that other guy who "invented" the maemo e.V.
<DocScrutinizer05>
it wuld have been absolutely legit when e.V wrote into own bylaws "the purpose of this e.V is to manage the assets of maemo community as represented by council, in best interest and according to requests from those entites. Any change of this purpose is impossible. The number of members in the e.V is limited to 12. The e.V board of directors will step down and quit the e.V and the remaining GA acceopts new members according to council's
<DocScrutinizer05>
instructions (based on a maemo election or referendum as described in [URL]) whenever council announces 'red button' event"
<DocScrutinizer05>
don't tell me this can't get done, with slightly smarter wording in bylaws of an e.V. - I know it could
<DocScrutinizer05>
it's absolutely possible to limit the number of members in an e.V. - and when it's possible to limit mebership to maemo garage members, then why shouldn't it be possible to limit membership to 12 *elected* garage members
<DocScrutinizer05>
but noooooo, this guy planned to "improve democracy" and allow community to "participate directly, without [evil] council in between" (please don't ask me to find the post where he uttered that approach of him)
<Oksana>
And now he placed [evil] GA in between?
<wpwrak>
DocScrutinizer05: you still have a lot to learn about populism ;-))
<Oksana>
Okay, who can change the Bylaws? Board or GA, right? And can Board be ordered by Council to change the Bylaws?
<wpwrak>
ask any populist, and you'll find the purest goodness in their supposed motives. mother theresa would be an evil witch in comparison to their noble standards.
<wpwrak>
of course, when you look at their actions, erm, some discrepancies may emerge :)
<Oksana>
Because Board was made to execute rulings of Council and-or GA, not to make decisions (changes in Bylaws) by themselves?
<DocScrutinizer05>
((<Oksana> And now he placed [evil] GA in between?)) not "in between" since GA is not elected by community in any way. It's _supposed_ to _be_ the "new" community. A complete delusion
<DocScrutinizer05>
it's correct that any e.V needs a GA. It however is not correct that an e.V cannot limit the members of such GA to only those voted for by maemo community in good ole maemo elections
<DocScrutinizer05>
and those members could do holy vow that they obey whatever ruleset they accept to be theirs. The e.V rulings would offer such ruleset which says that they act in best interest of maemo and obey the obligations to exit the eV when their term ends etc
<DocScrutinizer05>
any claims that it's illegal to waive any such rights to disobey external requirements, is nonsense
<Oksana>
"in between" because GA is subset of community. Not Martians. And yes, that would be an interesting approach. Since Council members already tell their full name and such (unlike community at large), Council=e.V. sounds easier than e.V.=community
<DocScrutinizer05>
o.O
<DocScrutinizer05>
who said "council == e.V" ?
<Oksana>
?
<DocScrutinizer05>
they are two different entities
<Oksana>
:s/e.V./GA/
<DocScrutinizer05>
with different people. Just like now there's a HiFo board and a council
<Oksana>
Sorry for mistyping.
<Oksana>
Since Council members already tell their full name and such (unlike community at large), Council=GA sounds easier than GA=community
<DocScrutinizer05>
well, council could be == GA, but that's not a requirement. I rather would _not_ do that, to keep council under control as well. The mutual control as established by HiFo bylaws was just brilliant
<DocScrutinizer05>
council controls HiFo/e.V and e.V/HiFo controls council
<DocScrutinizer05>
that's how proper democratic structures work
phre4k has quit [Ping timeout: 265 seconds]
<DocScrutinizer05>
that's the "red button" mutual right to call elections of _both_ bodies, in HiFo bylaws
<DocScrutinizer05>
when either entity misbehaves, both entites step down and community elects new personal
<DocScrutinizer05>
but forget about it, a certain guy will tell you "it's too late now, the e.V and the bylaws already exist"
<DocScrutinizer05>
IOW "we already hijacked the maemo 'community' and all their assets"
<Oksana>
Bylaws can be changed, cannot they? And, Board executes Council's and GA's rulings. If people find that Council==GA option suits them better, wouldn't Board have to agree to change the Bylaws?
<DocScrutinizer05>
funny enough when I raised same concerns earlier, I've been told "we can adjust all that later! for now it's just important to get the thing running"
<DocScrutinizer05>
again, I think council==GA is a *very* poor decision
Bonnie-Rotten has joined #neo900
<DocScrutinizer05>
the council by design is meant to be the community center of discussion and coordination and gets re-elected frequently. While the whole asset management is meant to have low workload and a very long term, so they don't need frequent reelections and weekly public meetings etc
<DocScrutinizer05>
those are to complementary domains and entites, which should _not_ be the same persons
<DocScrutinizer05>
two*
<DocScrutinizer05>
right now community votes for council and HiFo board. Why not just make the vote for council and e.V board from now on?
<DocScrutinizer05>
some guy will tell you "members of an e.V *cannot* get voted for by community" - incorrect!
<DocScrutinizer05>
sure the community cannot vote the members, but they can vote for the ones *entitled* to become member
Bonnie-Rotten has quit [Ping timeout: 240 seconds]
<DocScrutinizer05>
just like community cannot vote the board of a 503c(?) Pensilvania company, but they nevertheless vote the board of HiFo and then the HiFo conpany nominates those guys to be their new board.
<DocScrutinizer05>
actually I guess old parting board has to appoint the new board - by letters of law
<DocScrutinizer05>
the last one is both quite authoritative and informative
<DocScrutinizer05>
I know exactly what happened when the e.V guy asked those lawyers. He asked XY questions, and thus got lawyers' XY answers
<DocScrutinizer05>
~xy
<infobot>
xy is, like, The XY problem: You want to do X, but don't know how. You think you can solve it using Y, but don't know how to do that, either. You ask about Y, which is a strange thing to want to do. Just ask about X. http://www.catb.org/~esr/faqs/smart-questions.html#goal
<DocScrutinizer05>
>> Das Parlament heißt Mitgliederversammlung 9 – 13 <<
<DocScrutinizer05>
(the e.V's parliament is the GA)
<Oksana>
Is necessary for Board to be elected by GA?
<DocScrutinizer05>
GA can appoint and fire everybody in e.V.
<DocScrutinizer05>
GA is top authority in every e.V.
<DocScrutinizer05>
so there's no question like "what happens when council and GA disagree"
<DocScrutinizer05>
GA could even abolish *e.V.* council
<DocScrutinizer05>
unless they elected for a e.V. ruling that says "the GA cannot do this, and cannot change this very rule that they cannot do this"
<Oksana>
See? That's confusing. If Board is controlled by GA completely, and Council and Board should be equally controlling each other, then what is GA? Should GA consists of Board+Council?
<DocScrutinizer05>
but then, same way they can say "we will obey Maemo Council"
<DocScrutinizer05>
GA is what GA defines it is
<DocScrutinizer05>
GA and bylaws define what GA is, end of the day
<DocScrutinizer05>
that's why a lot of rules need to say explicitly that GA canot change them, ever
<DocScrutinizer05>
once the GA approved those rules, they are fixed
<DocScrutinizer05>
or you say "such rules can only get changed by 100% of meber votes, no matter if attending the GA or not"
<Oksana>
Let's say.... Community elects Board (once a year) and Council (once every 6 months), Board+Council is GA, Board obeys GA's rulings... That's would be recursive-funny.
<DocScrutinizer05>
sorry, AGAIN: council != GA
<DocScrutinizer05>
the council shouldn't be members of the e.V even
<DocScrutinizer05>
(which basically means the same, since GA == all e.V members)
<DocScrutinizer05>
(all that attend the assembly)
<Oksana>
Majority during GA's decision-making should be counted from all active-members, not just from those who attend-and-vote, to avoid accidental bias? That's a sane thought, but governmental voting systems rarely ever do this (except for compulsory voting in some places). Simply because no decisions would ever be made (unless number of voters is really small, like, 12).
<DocScrutinizer05>
please think "community elects e.V. once a year" and the e.V ( == GA) consists of 10 persons who elect a board of 3 out of them
<DocScrutinizer05>
the council shuld be completely detached from all this
<DocScrutinizer05>
it just coordinates the election for e.V./HiFo
<DocScrutinizer05>
threre is no reason why council must be an entity *inside* e.V (don't believe when somebody tells you different). the whole e.V may promise to listen to whomever they decide to, e.g. an external maemo council. There's however a lot of reasons why council should NOT be an entit<y inside e.V.
<DocScrutinizer05>
see above: recursive control, vs sane democratic mutual control of two independant entities
<DocScrutinizer05>
for same reason the GA should not get allowed to grow arbitrarily, since that would result in schizophrenia of the whole thing: community by council vs "community" by GA
<Oksana>
Ok... So, the differences from currents state of things would be: 1. e.V. active-members are elected by Community, instead of chaotic self-nomination; 2. red-button mutual-control is more clearly stated.
<DocScrutinizer05>
but again: it's perfectly sane for a e.V. to limit number of own members to arbitrary value of e.g. 10 or 12 or 20, and have that in the e.V's bylaws even
<DocScrutinizer05>
yes, that#s basically all it needs
<DocScrutinizer05>
plus a few words in bylaws or rulings that the purpose of e.V is solely to execute what council asks for (unless there are some legal concerns detected or the board *and* GA think the council gone rogue)
<DocScrutinizer05>
maybe a few words about when to call for a referendum or the red-button would also help: e.g. when at least 30 community members ask for it, in writing to the council or board
<DocScrutinizer05>
duh!
<DocScrutinizer05>
I actually think it's a flaw in council's rules that there's no such thing like those 30 requests defined for starting a referendum
<DocScrutinizer05>
but then otoh when council refuses to start a referendum about X and board thinks they act rogue, then board can threaten council with red button
<DocScrutinizer05>
so maybe no 30 request threshold needed, just common sense
<DocScrutinizer05>
the red-button thing is better than 500 pages of rules
<DocScrutinizer05>
it deals with the unforeseen
<DocScrutinizer05>
qualification for becoming an e.V/board member: knowledge about contracts, and reliability for the next at least 12 months. Qualification for council: knowledge about community and what the community wants (plus ideally a throrough understanding of maemo's history and organizational needs and structures)
<DocScrutinizer05>
basically the e.V/board members don't need to know a thing about maemo at large
<DocScrutinizer05>
if we could afford, we would hire somebody, a lawyers office or somesuch
<DocScrutinizer05>
this would even be *better* than havong people in board/e.V that have whaever individual interest in maemo at large
<DocScrutinizer05>
the e.V/board must not have own interests. The individuals - if they have - have to execute those interests same way like any other ordinary maemo community member
<DocScrutinizer05>
voice them in a weekly council meeting, or at arbitrary time and media towards any council member
<DocScrutinizer05>
council is obliged to listen and act upon such requests
<DocScrutinizer05>
honestly, is all this soooo complicated and that#s just me who thinks it's obvious?
<Oksana>
Who would be doing the hiring? The Council? Who would carry the responsibility for the decision to hire somebody - individual members of the Council? Or would the Council need to be a legal body? That's what Board is - legal body to do whatever needs to be done, without creating impression that the bank-account and maemo-name belong to a private person, or a group of private persons.
<DocScrutinizer05>
traditionally so far the council was the entity to hire. See council rules
<DocScrutinizer05>
legal comtracts so far been done by Nokia, but council was the one to hire and fire, and Nokia executed
<DocScrutinizer05>
(unless council came up with nonsense like "hire Steve Jobs")
<DocScrutinizer05>
it's a pity that council never executed that right they had (afaik)
<DocScrutinizer05>
note that >>Being able to represent the community to Nokia<< is point #5 on a list of 6 points about tasks/purposes of council
infobot has quit [Ping timeout: 240 seconds]
sparetire_ has quit [Quit: sparetire_]
<DocScrutinizer05>
Oksana: ((councils merged)) guess who drafted >70% of http://maemo.org/community/council/councils_become_finally_one/, and that announcement been made unanimous by complete HiFo and council then, no matter what some peeps now say that they felt unhappy back when. That's irrelevant how they felt, they agreed on this statement
<DocScrutinizer05>
since then there's *one* council that nevertheless obeys rules of both former councils
<DocScrutinizer05>
((point #5)) means it's pretty much at end of list. The fact that there's no Nokia anymore now doesn't suggest council is not needed anymore. Basically nothing changed for council from Nokia vanishing - not even the "we're on our own now", since the council been "on its own" for years already
lexik|m has quit [Quit: Connection closed for inactivity]
<DocScrutinizer05>
what changed from Nokia's side: they instructed Nemein to grant server root access to *me* and *warfare*. They asked council and HiFo whom to grant root access. Same time they stopped paying Nemein for doing the server administration.
<DocScrutinizer05>
HiFo at that time been one patent lawyer basicaly, and that one had no real clue about the issue and thus agreed on council's suggestion
<DocScrutinizer05>
grr qwest.net again down
<Oksana>
What's the problem with it? If I understand correctly, HiFo continued to pay Nemein for doing the server administration?
<DocScrutinizer05>
no
<DocScrutinizer05>
I built a team I called techstaff and that team now does server maintenance
<DocScrutinizer05>
Nemein is out
<DocScrutinizer05>
far out
<Oksana>
Ok, so this channel should not be existing any longer? irc://freenode/nemein-maemo-infra
<DocScrutinizer05>
this channel is completely obsolete
<DocScrutinizer05>
I actually wonder where from you got that
<Oksana>
I just used /msg alis list *maemo*
<DocScrutinizer05>
:-/
<DocScrutinizer05>
this channel is supposed to be hidden. It's not really public
<DocScrutinizer05>
never been
<Oksana>
I wish I knew who mashiara is. jyrjyr, I know, has a problem with his IRC client; here, too: irc://freenode/maemo-meeting
<DocScrutinizer05>
it's one of the channels we used internally to organize administration and here particularly handover from nemein to maemo techstaff
<DocScrutinizer05>
mashiara == Rambo = Eero, a Nemein former maemo sysadmin
<DocScrutinizer05>
anyway, I think we had our share of off-topic on this channel now ;-)
<DocScrutinizer05>
good luck with your first council term, no doubt you'll be one of the 5
<Oksana>
Thank you. I received the parcel from Digikey, by the way. Seems fine, but I will wait (and research) for one or two weeks, before trying to attach microUSB to the board.
<DocScrutinizer05>
and practice ;-)
<DocScrutinizer05>
Oksana: ((e.V. laws, http://www.amtsgericht-zeven.niedersachsen.de/download/75707 )) actually the board (vorstand) may even have non-members: >>Weiterhin sind Personen, die nicht Mitglieder sind, und Minderjährige wählbar<<
<DocScrutinizer05>
fwiw
<DocScrutinizer05>
there's pretty few _real_ legal requirements, IOW you can do virtually all you want in e.V bylaws/regulations
nicksydney has quit [Quit: No Ping reply in 180 seconds.]
<Steven__>
Has there been any talk about user-replacable board modules for the neo900? Sort of like miniPCIe for laptops. It occurred to me that you could use microSD slots for generic SPI devices, like sensors.
<APic>
Not seen any, but sounds desirably.
<Humpelstilzchen>
didn't we have usb host or i2c?
<APic>
USB Host works, yah
<APic>
With original N900
<Steven__>
I know modular boards add complexity/price/volume, but it could extend the use cases and lifespan of the design.
<kerio>
oh you mean internal stuff
<Steven__>
How would the user/hacker access the I2C bus?
<Steven__>
Well, it coud be either.
<kerio>
hackerbus!
<kerio>
i don't think there's space inside
<kerio>
it's got usb otg
<Steven__>
Hmm.
<Steven__>
OTG?
<kerio>
automatic slave/host switching based on the cable
<Steven__>
So they plug into where the microUSB is now?
<Steven__>
Is there going to be anything, say, for the backplate?
<Steven__>
I mean, that compartment.
<Steven__>
I am thinking that you have two options for user-added expansions that would be inside the case: offer an optional wider spacer, or offer a connection for backplates that would give more room for that compartment.
<mvaenskae>
Steven__: how can one add more space to the n900's case? :)
<Steven__>
If you wanted modular boards inside the case and you allowed for a wide spacer, you could have areas on the motherboard that are not assembled that are for periferal/daughterboard connectors.
<Steven__>
Doesn't the neo900 already require some sort of spacer for a wider motherboard?
<Steven__>
i.e. you are bringing the keyboard and screen upward.
<Steven__>
Thicker I mean, not wider.
<Steven__>
I thought I read that somewhere...
<mvaenskae>
ahhhh, yeah thickness is a bit of an issue i believe
<Steven__>
The alternative could be a connector for boards in the battery area, by using an expanded backplate.
<Steven__>
Hmm. With a little cutting, the diagnostic port area could be turned into a more convenient hole. I bet a ribbon cable could be tucked around the battery.
<Steven__>
These are just random ideas. I don't really know much about the current design, other than what is in the news articles.
<DocScrutinizer05>
we got hackerbus for that
<Humpelstilzchen>
what is hackerbus
<DocScrutinizer05>
a connector for custom extensions in battery compartment
<Humpelstilzchen>
hmm a custom bus? Why not stick to something standarized like i2c?
infobot has joined #neo900
Oxyd76 has quit [Remote host closed the connection]
Oxyd76 has joined #neo900
<DocScrutinizer05>
wow
<DocScrutinizer05>
~wb
<infobot>
thx
<DocScrutinizer05>
~+uptime
<infobot>
- Uptime for purl -
<infobot>
Now: 7m 52s running infobot 1.5.4 (SVN) -- linux
<infobot>
1: 59d 8h 41m 19s running infobot 1.5.4 (SVN) -- linux, ended Sun Nov 14 18:39:57 2010
<DocScrutinizer05>
anyway we don't have such critter, What omap has is a "general purpose" DSP
<Humpelstilzchen>
also fine, never tried one
<DocScrutinizer05>
that DSP maybe even can do IO via IP like UART and USB etc, maybe even I2C, but hardly GPIO
<DocScrutinizer05>
afaik the DSP is "linked to" the system by DMA channels, basically
<DocScrutinizer05>
I might be wrong here
mvaenskae has quit [Ping timeout: 244 seconds]
<DocScrutinizer05>
but meh, the ARM core is fast enough for quite some sophisticated bitbanging
<Humpelstilzchen>
sure
<DocScrutinizer05>
werner always argues with me that a linux can't do proper realtime tasks, due to scheduler etc. I say that's linux' problem then, the hardware is good enough and doesn't need further fancy coprocessors just to help linux out of own hole
<DocScrutinizer05>
:-)
<Humpelstilzchen>
nah its not that bad if you use the fifo scheduler
<DocScrutinizer05>
:nod:
<DocScrutinizer05>
my thoughts exactly
<Humpelstilzchen>
just don't something important ;)
<DocScrutinizer05>
tweak the scheduler til it bleeds, but the hardware is well capable to do MHz of bitbanging, and the dang scheduler just needs to learn to behave
<DocScrutinizer05>
I'm a hardcore hardware guy, I'd simply suspend the complete linux incl scheduler and all, and run my top level IRQ handler on each timer interrupt
<DocScrutinizer05>
;-D
<Humpelstilzchen>
poor OS
<DocScrutinizer05>
or... simply lock *all* IRQs as first action in my code
<DocScrutinizer05>
no silly scheduler will stop me from doing proper bitbanging on a 1GHz ARM core
<kerio>
what the fuck is bitbanging
<DocScrutinizer05>
tiny little supervisor, run my bitbanging as one task and linux kernel as the other task
<DocScrutinizer05>
kerio: togling GPIO to run protocols like I2C or UART in software
<kerio>
ah, timing-sensitive stuff
<DocScrutinizer05>
yep
<kerio>
can't you just nice -20
<DocScrutinizer05>
nope3
<Humpelstilzchen>
with i2c as master not realy sensitive
<DocScrutinizer05>
this only determines how often your task runs, but not how long
<DocScrutinizer05>
Humpelstilzchen: exactly, I2C is not that timing sensitive at all
<DocScrutinizer05>
we got other stuff that might be: SPI to control radio frontend of NFC directly
<DocScrutinizer05>
but honestly I don't see exctremely timing critical stuff in that task either
<DocScrutinizer05>
particularly since the protocol simply retries when anything fails
<Steven__>
Where is the hackerbus connection going to go in the case?
<Steven__>
Is it replacing the diagnostic test pads?
<Steven__>
Or is that not decided yet?
<Steven__>
Looks like on the schematic it is listed as "SD breakout", so I guess it replaces the SD slot.
<Steven__>
Though I don't see a layout, so I could be misinterpreting this.
APic has quit [Quit: *hiccup*]
<wpwrak>
DocScrutinizer05: i;m not saying that you "can't" do such things with the big mean main CPU. just that it's perhaps not the best idea. e.g., you may be able to use a 747 to drive down to the supermarket, but it may just be a bit impractical and expensive :)
<Steven__>
That sounds like a very interesting idea there...
<Steven__>
I think the DHS would be interested in it too, if they saw you doing it.
<Steven__>
Lol.
<wpwrak>
DocScrutinizer05: NFC has 1) timing-critical, 2) IO-intense, and 3) analog (the SWP current sensing). doing it all with the main CPU may cost you more in external chips you need than the cost of the MCU. and it will probably be less flexible (e.g., with the MCU, you can easily adjust the threshold voltage)
<wpwrak>
Humpelstilzchen: FIFO scheduler alone isn't enough. that's okay for RT that can accept latencies in the order of a few ms. we need much higher accuracy. so you'd have to put a separate RT kernel under the Linux kernel.
<Humpelstilzchen>
wpwrak: that depends on what someone needs...
<wpwrak>
Humpelstilzchen: that exists, of course. but you than have a fairly unusual kernel setup, increasing your maintenance overhead. also, it will still be difficult to get this sort of precision. e.g., you soon have to worry about bus arbitration and such. e.g., background DMA can really spoil your day.
<DocScrutinizer05>
hmm, more external components than a MCU... I guess we have a spare comparator in one of the chips we already need. I don't see *any* extra BOM except the shunt for SWP
<wpwrak>
Humpelstilzchen: yes, as i said - these protocols we're dealing with there have pretty nasty timing requirements. they're expected to be implemented in hardware. think "big-banging USB". could it be done ? of course. has it been done ? yes. would you want your big mean OMAP have to do it ? probably not.
<DocScrutinizer05>
while adding a in-circuit-programmable (by main CPU) MCU is a nightmare tregarding BOM and design and debugging
<Humpelstilzchen>
wpwrak: I never said I want to bitbang usb..
<wpwrak>
Humpelstilzchen: it's on that scale of things. not quite as tight timing, but close
<DocScrutinizer05>
Humpelstilzchen: sorry for werner. He got his weekly 5 min of "I want a MCU", you just got into the line of fire
<Humpelstilzchen>
wpwrak: I did some on a Cortex A9 600MHz, worked fine unless fired a few 100 extra threads
<Humpelstilzchen>
wpwrak: again it highly depends on the requirements
<DocScrutinizer05>
lemme put this clear: as it stands right now I'd rather drop a complete function rather then get a MCU
<wpwrak>
well, that would solve the problem ;-)
paulk-collins_ has quit [Quit: Quitte]
* Humpelstilzchen
would vote for a Zynq-7000 (thats an ARM and FPGA one one chip) ;)
<DocScrutinizer05>
I got better ways to "solve the problem" though
<wpwrak>
anyway, i got other things to do. so i'll leave you to pondering how to best waste resources ;-)
<Steven__>
Isn't this how technology has been heading? I open up a laptop and I see more than half a dozen microcontrollers.
<Steven__>
Used to be all hardware.
<DocScrutinizer05>
ooh, so being economic on BOM is "wasting resources" now?
<DocScrutinizer05>
Steven__: how many of those microcontrollerss are meant to be used in a small embedded system as main CPU and yet are used in your case as a coprocessor with in-circuit firimware upload and startup, suspend, and shutdown in sync with and under control of the ARM SoC?
<kerio>
ayy lmao
<Steven__>
Well, none of them are the main CPU. I don't have much experience with embedded, but with some of the laptops I have done maintenance on it looks like nearly all tasks are rolled into micocontrollers with a few built-in cores for that task, excepting the stuff for managing high-speed busses (that is usually hardware).
<Steven__>
I remember taking apart a DVD drive and it had three microcontrollers in it. One for the lasers, one for the motors, and one for talking to the computer.
<DocScrutinizer05>
I attribute that to your lack of experience with hw design at large then
<Steven__>
I wasn't trying to flame you. I was just making a comment.
<DocScrutinizer05>
yes, and every of those three MCUs was basically autonomous and had no firmware upload option in normal operation from any of the other MCUs involved
<DocScrutinizer05>
and they definitely were not designed to operate at microWatts while not active
<DocScrutinizer05>
bringing up a system with multiple CPU cores under your (main CPUs) control re software and startup/shutdown, and making +sure* the whole mess never runs nto a busy idle burning energy for nothing, never locks up so you nbeed a battery removal to reset, and never has leak currents when it's supposed to not consume *any* energiy since you want the subsystem to be idle/shutdown - that's basically a nightmare
<Steven__>
As I said, I don't know much about that. I just was just adding an observation about the large numbers of microcontrollers found in some kinds of modern systems.
<kerio>
the n900 isn't modern :>
<Steven__>
I consider the N900 to be modern.
<Steven__>
It has USB doesnt it?
<Steven__>
Now... I still havent gotten this laptop from 1996 up and running...
<Steven__>
It only has 24 MiB of memory, so it is hard to find a distro that runs on it. Oh, and I dont have a second floppy drive, lol.
<DocScrutinizer05>
Neo900 already has about same number of MCUs
<DocScrutinizer05>
but none of them is a general purpose MCU tweaked into a field programmable coprocessor
<Steven__>
I see. That is what I was thinking of actually (specific use, not general purpose). I must have misunderstood what was being referred to.
<ds2>
the OMAP3 by itself probally has more MCUs in it then most "modern" systems :P
<Steven__>
Heh, I saw a hint of that just by looking at all the different kernel drivers and stuff for it.
<DocScrutinizer05>
((we need much higher accuracy. so you'd have to put a separate RT kernel under the Linux kernel.)) only when we planned to guarantee such accuracy while the normal linux system runs concurrently. Since we need control of such accuracy for only a max 500some ms total duration, we can simply stop linux scheduling completely during that timespan
<DocScrutinizer05>
mind you the maemo system is meant to be in zeroclock 99% of the time anyway, and it actually is, usually, for several seconds until CPU wakes up for another turn of activity for a maybe 10ms
<Steven__>
Those sound like long amounts of time for stopping the kernel. That doesn't cause a bunch of problems?
<DocScrutinizer05>
why would it?
<DocScrutinizer05>
the kernel stops itself for several seconds
<DocScrutinizer05>
since there's simply nothing to do - which is a madatory requirement to achieve decent standby time
<Steven__>
I guess it would only cause problems with sychronizing with external communications, but you should have control of the things with a low latency.
<Steven__>
How does audio/video work with that sort of set up?
<DocScrutinizer05>
the particular usecase (NFC) has no realtime response requirements of _any_ kind, for the start resp sync to such "external" communication. The reader that talks to our simulated card/tag will happily wait for years trying to sync to the occasional tag coming into vicinity
<DocScrutinizer05>
(how does) great! audio using buffers and DMA which wake up CPU when whatermarks reached. Video is a completely different sort of thing tht prolly doesn't leave much time for CPU to idle anyway
<DocScrutinizer05>
or maybe it leaves lots of CPU idle time while DSP burns away at 100%
<DocScrutinizer05>
tbh I don't care
<DocScrutinizer05>
all I know is: there's no fundamental problem in locking task switching for a 500ms
<Steven__>
Thats a pretty interesting way of doing it. I would've thought there would be some big challenges.
NIN101 has quit [Quit: No Ping reply in 180 seconds.]
<DocScrutinizer05>
so as soon a sNFC needs high accuracy atention, the handler can lock task switching and thus guarantee that it doesn't get preempted for next 800ms
NIN101 has joined #neo900
<DocScrutinizer05>
heck, if needed I'd dare to switch down video refresh for those 900ms
<wpwrak>
DocScrutinizer05: (has no realtime response) there are some slotted protocols that do require highly accurate timing. see the table in section 3.4.10, column "time-based"
<DocScrutinizer05>
(not that this would just faintly be necessary here)
<DocScrutinizer05>
please see as well, that timing requirement is *during* established session, no?
<DocScrutinizer05>
yeah, and how precisely at 4:23:54.00110345 AM must that anti collision start?
<wpwrak>
if you're a card, the reader will tell you
<DocScrutinizer05>
and how long witll it take until it got finished, once it started?
<wpwrak>
that's up to the reader to decide :)
<DocScrutinizer05>
the Neo900 can take 15s to prepare the system for those 800ms exclusive attention to bitbanging the anticolision protocol
<DocScrutinizer05>
it's really not like we have any *true* realtime requirements here
<wpwrak>
the standards leave it fairly open how you use anti-collision. so maybe a reader does anti-collision-from-scratch -> find one card -> handle that card -> anti-collision-from-scratch -> ...
<DocScrutinizer05>
it's under complete control of the system when to act on the external stimulus
<wpwrak>
but it could also do anti-collision-everything -> talk to first card -> talk to second card -> ...
<DocScrutinizer05>
*shrug*
<DocScrutinizer05>
I don't see the problem
<wpwrak>
or, worst case: anti-collision-from-scratch -> talk to first card -> anti-collide-some-more -> talk to second card -> ...
<wpwrak>
which means that, if you're one of the later cards and the protocol is one with slotted timing, you have to be ready to respond for quite a while
<DocScrutinizer05>
so worst case: Neo900 fails on anticollsision when other cards are in same reader's vicinity
<wpwrak>
yes, for instance
<DocScrutinizer05>
I can *easily* live with that
<wpwrak>
;-)
<Steven__>
I seem to recall reading that there are realtime patches for the Linux kernel. Could something like that be used to integrate this processing into the normal kernel scheduling instead of pausing kernel execution?
<wpwrak>
the next area where we have timing issues is SWP. there, we also have to act in response to things the reader sends. not sure about allowed latency.
<wpwrak>
Steven__: things get tricky if you have to operate in the (one-digit) microsecond range. the RT patches do allow you to do amazing things but i wouldn't be sure whether they would be good enough in this case
<wpwrak>
Steven__: but there's another issue: if you put the kernel on RT, then you also have increased kernel maintenance overhead
<DocScrutinizer05>
the latency is no issue since we already run the process that listens to reader. The SWP to SIM is clocked by SoC, so no timing issues at all, except jitter maybe
<wpwrak>
DocScrutinizer05: SWP kicks in mainly after anti-collision. so now you have to run the process that blocks out everything else beyond that point.
<wpwrak>
and yes, i'd worry about jitter. possible sources are DMA and cache.
<DocScrutinizer05>
as mentioned above, and freemangordon said it before: a session to a card is limited to a (iirc) 500ms total duration
<wpwrak>
i mean, i've done all that for ubb-vga. i have a pretty good idea where the limits are, and what i had to do there to have proper timing control was extremely intrusive.
<DocScrutinizer05>
sure it was, since you wanted a proper linux running concurrently
<DocScrutinizer05>
we don't
<DocScrutinizer05>
forget about the idea to schedule a worker thread for each 1us timer IRQ
<DocScrutinizer05>
lock scheduling all together, run the servicing handler exclusively in busy polling loops
<wpwrak>
with the mifare cards we have around here, i see latency in the range of 2-3 s. but i don't know how much of this is NFC and how much is talking to some server
<DocScrutinizer05>
well, even 5 s "stopping" normal execution of the rest of system won't kill us
<wpwrak>
(wanted ... running) no, i never went that far. i had to kill all interrupts, dma, etc., flush then preload caches, and so on.
<DocScrutinizer05>
actually it happens on N900 more often than we would like, sort of. When swap basically paralyzes the complete kernel
<Steven__>
Waiting for paging in memory from swap you mean?
<DocScrutinizer05>
waiting for the IO to finish, yes
<DocScrutinizer05>
IO is slow but extremely busy
<wpwrak>
some peripherals don't like it if you don't answer their interrupts. and many drivers aren't all that good at recovering from upset peripherals. of course, that's a driver bug in the end, but expect to be fixing a lot of interesting bugs that nobody else sees ;-)
<Steven__>
It is worse on SD-cards, if that is where the swap would be, because the page size is huge.
b1101 has quit [Quit: b1101]
<wpwrak>
and during swapping the kernel is still quite responsive. you just don't see it :)
<Steven__>
My new SD card that I bought has a 16kiB page size.
<DocScrutinizer05>
wpwrak: on Neo900 when we have a peripheral that gets pissed when not answering its IRQ then we got the wrong peripheral
<wpwrak>
;-)
<DocScrutinizer05>
it's not like an OMAP system and particularly maemo works
<DocScrutinizer05>
the CPU usually is in zero clock, and I guess - though short for human time scale - the latency to wake from zeroclock still is an eternity for such IRQ answering you mention
<wpwrak>
oh, really ? :)
<DocScrutinizer05>
generally there must not be a peripheral that out of nowhere asks for real time IRQ service
<wpwrak>
anyway, once you've slain the anti-collision dragon and the SWP dragon, there's the "raw mode" lurking. do you want to support that at all ?
<DocScrutinizer05>
there might be free fall IRQ from accel, but when missing that IRQ it's not a problem for the peripheral neither for the kernel and core system. It's solely a problem for the app
<DocScrutinizer05>
yes, I want to support all that. For 1000ms
<wpwrak>
ah well. i rest my case ;-)
<DocScrutinizer05>
on interactive request from user, with maybe up to 10s latency until that hot period starts
<DocScrutinizer05>
but honestly, I don't care. I know the hardware can do it. Up to the software dudes to make it happen, I could care less about what it needs on tweaks and hacks to the system
<DocScrutinizer05>
I just can give advice how it +could* get implemented
<DocScrutinizer05>
and the simple trick is: don't allow interrupts of your handler for the duration of NFC communication
<kerio>
DocScrutinizer05: (re: free fall IRQ) it's probably a problem of the device :>
<DocScrutinizer05>
kerio: only when you got parachute extension, or when the device is religious and wants to have a last prayer until impact on floor
<kerio>
no no
<kerio>
if those were the case, there wouldn't be a problem
<ShadowJK>
swap does not paralyzer the entire kernel. If you have a very small process, or something that doesn't use alot of ram, it'll keep running happily even if everything rest is blocked due to swap activity
<DocScrutinizer05>
ShadowJK: swap doesn't. But IO does, aiui
<ShadowJK>
Nope
<ShadowJK>
around 30Mbyte/s does cause some CPU load, true, but it doesn't block or stall the kernel
<DocScrutinizer05>
doesn't the kernel lock waiting for the DMA to finish (however stupid that seems)?
<ShadowJK>
No
<ShadowJK>
But it looks like it does, because anything interactive is slowed down massively
<DocScrutinizer05>
well, unsuitable example then. Anyway maemo defintely can cope with periods several 100ms of no IRQ at all, see zzztop
<DocScrutinizer05>
for the system there cannot be a difference between 2000ms C5 and 2000mS CPU running in busy loops and no scheduling at all
<ShadowJK>
WHen you tap the touchscreen, the code that deals with handling touchscreen events isn't in RAM anymore, so it has to wait for that to be read in. Once that's done, the touch event is hten passed on to X, then to the app, then back to X, etc. Even in the ideal case of the code and data required in X and the app being minimal, you're still looking at half a dozen latency events, where "latency event" is in the case of SD card on the order of 5-10seconds
<ShadowJK>
2000ms is a bit high for running without interrupts, but otherwise yeah
<Steven__>
Hmm, I wonder if you could put RAM on an SD card without too much trouble.
<ShadowJK>
Oh hey did you hear about Jolla's newest software update? They turned the lever so far towards "don't ever stall or lag", that the OS now starts killing stuff when free memory (NOT counting swap!) drops below 200M
<kerio>
LOL
<kerio>
hold on now
<kerio>
...doesn't that mean that jolla devices have effectively 200mb less ram and no way to use swap
<DocScrutinizer05>
:-o
<ShadowJK>
Nah it can still use swap
<DocScrutinizer05>
kerio: excellent point
<ShadowJK>
It just uses less swap
<Steven__>
The kernel should swap things out pre-emptively even with free RAM if the process is idle. At least thats what I thought.
<Steven__>
That is, if your swapiness is high enough.
<DocScrutinizer05>
depends on swappiness
<ShadowJK>
also they took away 100M of ram for zram (zswap? compcache?)
<DocScrutinizer05>
dang
* DocScrutinizer05
feels like back in the 1990s
<ShadowJK>
There's more than one "Hey I opened browser and all my open apps vanished?!" posts now
<DocScrutinizer05>
only that back when somebody said "640kByte are enough for everybody"
<DocScrutinizer05>
LOL
<Steven__>
BTW Are there any settings for optimizing swap besides swapiness? The kernel page size is 4096 IIRC, but flash pages sizes are much larger. AFAIK you cannot swap out huge pages without first turning them into small pages. It would be nice to somehow tell the kernel that it should swap things out in pages that are the same size as the flash pages.
<ShadowJK>
Steven__, it doesn't really work
<ShadowJK>
The stuff in N900's kernel is close to optimal for flash
<ShadowJK>
Even if the erase block size on SD cards are around 4M-12M now, you can still write to them sequentially in smaller blocks without penalty, it's when writes are non-sequential that the issues start. In N900 kernel, whenever it writes something to swap, it looks for free area in swap at a position higher than the last position (doesn't look back)
<ShadowJK>
Whereas for harddrives, you'd look for free position closest to current posotion (look back, look forward)
<Steven__>
It is the read size that I am more concerned about.
<ShadowJK>
It gets slower once it reaches the end of the swap and starts over, because then the entire swap area is kinda filled with small fragments already
<ShadowJK>
Reads are more or less "free" for any read size
<ShadowJK>
atleast compared to writes
<Steven__>
My SD card has 16kiB pages, and my research suggested to me that reading only a part of the page takes a similar amount of time to reading the whole page.
<ShadowJK>
that might be, but it's a question of microseconds vs microseconds. It's not like with writes, where a sequential write of 4kB can complete in 20 milliseconds, but a write of 4kB far away from where you last wrote to can take 2 seconds
<Steven__>
I suppose so, but isn't reading from swap more latency sensitive than writing, assuming your swapiness is set correctly?
<DocScrutinizer05>
you should trust ShadowJK, he kows his flash stuff and swap
<Steven__>
It is not a matter of trust, but of understanding.
<DocScrutinizer05>
sure, go ahead :-) just saying: you got the right expert to ask
<Steven__>
Ok, cool. =)
<DocScrutinizer05>
you're lucky
<ShadowJK>
You can make the kernel read in larger chunks, /proc/sys/vm/page-cluster
<Steven__>
What I was thinking was this: If a program is idle and the swapiness is at a good setting it will be swapped out, but it is in the background and so it doesn't matter that much how long it takes. If a program comes out of being idle it can be unpredictable and so how quickly you can read that memory back becomes pretty important.
<ShadowJK>
2^page-cluster number of pages (4k)
<ShadowJK>
It reads more stuff that is close by to the stuff it would otherwise read in
<ShadowJK>
where "close by" doesn't correlate to "read more in of app X"
<Steven__>
Hmm, yes, I suppose so.
<ShadowJK>
Because stuff is swapped out on a "least used" basis, stuff that hasn't been used for the longest goes out first. So, stuff is in pretty random order in swap
<Steven__>
Unless you have a solution that keeps the fragmentation low.
<Steven__>
Someone recommended a utility called flopswap to me earlier.
<Steven__>
That switches between two different swap areas so that the kernel rewrites the swapped out memory. I haven't looked too deeply into it yet though.
<DocScrutinizer05>
that's for defragmentation
<DocScrutinizer05>
you also might want to read about swappolube
<Steven__>
Yes, that was my point though. If it is defragmented then it is more likely that related memory is swapped out next to each other.
<DocScrutinizer05>
flopswap is kicking in when swap "turns around" as ShadowJK explained above
<DocScrutinizer05>
no
<Steven__>
No?
<DocScrutinizer05>
it simply "copies" swap pages from one volume to the other
<DocScrutinizer05>
closing any gaps in between
<DocScrutinizer05>
thus defragmentation is prolly the wrong term. Rather call it unscattering
<Steven__>
Wouldn't that mean that when something is swapped out, it gets allocated a portion of the SD that is all together?
<DocScrutinizer05>
swap doesn't contain fragmented files of random size
<Steven__>
Well, its not exactly fragmentation, but I thought that it was solving an analogous problem.
<Steven__>
i.e. that newly allocated space for swapping something out is not allocated in one big chunk, but lots of little ones.
<ShadowJK>
Steven__, even with low fragmentation, the "read-ahead" provided by tweaking page-cluster wouldn't get you an entire app, or big chunks of an app read back in, because big chunks of apps are not written out in the first place
<DocScrutinizer05>
I dunno which precedence the swap pages take when getting swapped out to new vilume after they got swapped in from old volume a millisecond before. For sure not ordered by app or whatever
<Steven__>
Oh.
<Steven__>
So it really wouldn't give you any performance advantage to change it I guess.
<ShadowJK>
Well it might by pure luck ;-)
<Steven__>
I guess if your system is really from swap a lot, it might be likely that you get something else your looking for.
<DocScrutinizer05>
flowswap just concatenates holes. It cannot merge swap pages
<ShadowJK>
Con Kolivas had at one point a "swap readahead" feature, that would when system was idle, read in swap , but mark put those pages last (or first, i dunno the convention) on the LRU list, so that if there was any memory pressure, those readahead pages would get dumped from memory first
<ShadowJK>
So ideally you'd want these opportunistically read pages to be marked in the same way, but i dont think that happens when they're read-ahead through page-cluster tweakable
<Steven__>
Sounds like it would require a kernel patch to optimize it further.
<DocScrutinizer05>
what is needed is ... MOAR RAM ;-D
<Steven__>
Indeed!
<DocScrutinizer05>
and smarter apps, written with resource economy in mind, not with "duh, dotnet is cute"
<Steven__>
Actually, I had a question about that with the Neo900. The Xmas update said that 1 GiB RAM chips were ordered specifically because they were getting hard to find. Why didn't the design use a larger amount of RAM in a similar package?
<DocScrutinizer05>
OMAP3 address spavcve: 1GB
<DocScrutinizer05>
space*
<Steven__>
Oh.
<DocScrutinizer05>
physical
<Steven__>
Okay. That seems too bad. It is only a little "MOAR". =)
<Steven__>
Still a huge increase over the N900.
<DocScrutinizer05>
and even that needs "tricks" (chip select 1/2)
<DocScrutinizer05>
logically it already uses 2 banks of RAM for 1GB
<DocScrutinizer05>
that's the limit
<DocScrutinizer05>
I bet omap5 can address more
<Steven__>
So no 64 GiB RAM anytime soon I guess? =)
<DocScrutinizer05>
on Neo900? definitely not
<Steven__>
I am imagining a bunch of SODIMMs sticking out of the back.
<DocScrutinizer05>
I hardly can imagine what for we would need even 1GB
<DocScrutinizer05>
burn insane web pages with fire, and live happily with 512MB ram until the cows come home
<DocScrutinizer05>
I mean, the RAM of Neo900 easily can store the complete raw data of an entire audio CD
SylvieLorxu has quit [Remote host closed the connection]
<DocScrutinizer05>
computers worked great (sometimes I think, better than nowadays) when the data of a CD was *lots* and held all data of entire program packages incl mapped data and whatnot
<Steven__>
Weren't most PCs single-process systems then?
<DocScrutinizer05>
yes, and still they worked. Often faster than nowadays, with quadcore 3GHz cpu
SylvieLorxu has joined #neo900
<Steven__>
Well, that is because every 18 months, the amount of processing required for everyday tasks doubles.
<DocScrutinizer05>
I still wait to see somebody giving me a sound example why you need 1GB RAM
<DocScrutinizer05>
no, that's because each 18 months the coders get double as lazy and unprofessional
<Steven__>
Exactly.
<DocScrutinizer05>
except for a very few high complexity simulation tasks (gaming, mainly) I don't see where computing requirements of daily use increased for any good reason
<kerio>
<doc> things were better when *I* was young!
<Steven__>
Lol.
<Wizzup>
Steven__: I don't think the need doubles really.
<Steven__>
Back in the good old days your program was stored by the way you plugged the wiring into your computer...
<Wizzup>
I still get by just fine with a single core 1-2Ghz machine
<Steven__>
Wizzup: It was a joke.
<Wizzup>
okay
<Steven__>
I use the X60/T60 mainly, which is dual-core, but I don't use all of the system resources.
<Steven__>
(or can have a dual-core)
<Steven__>
I do have problems with memory though, but it's Firefox causing the trouble all by itself...
<Steven__>
It's using 22.6% of my memory right now, and Xorg is using 0.9%.
<Wizzup>
Do you mean adblock?
<DocScrutinizer05>
it's always the browsers (and KDE and its memleaks) which cause the RAM shortage
<DocScrutinizer05>
and inside browser, it's mainly the "web code" at large, be it JS or whatever is the hype of the week
<DocScrutinizer05>
and the "web programmers" who think they are writing code while actually .... *cough*
<Steven__>
Hmmm.
<Steven__>
From about:memory : 171.57 MB (26.13%) ── heap-unclassified
<Steven__>
I can't even see what that all breaks down into.
<DocScrutinizer05>
"look, I managed to mage the letters jump! doesn't it look cute?"
<DocScrutinizer05>
make*
<Steven__>
Addons is only ~9% of Firefox's memory.
<Steven__>
I have felt dissatisfied with Firefox for awhile now, but there aren't many choices with its feature set.
<DocScrutinizer05>
well, there are other 'nice' ways to eat insane amounts of memory: e.g. use pictures of 60Mp size, scaled down in rendering engine of browser to fit into that button. Stuff like that
<Wizzup>
23:27 < Steven__> Addons is only ~9% of Firefox's memory.
<Wizzup>
Are you sure?
<Steven__>
No, but that's what it says.
<DocScrutinizer05>
well, the program text for sure
<Wizzup>
Most of my mem usage with firefox is due to my usage of adblock. Which is commonly believes to eat a lot of ram
<Steven__>
Generate a random password per-service and keep it in an encrypted file.
<DocScrutinizer05>
prolly because of my thought "everybody creates cheap content, pimps it up with jigabytes of JS eyecandy and crap, and joins adclick money machine, to earn from poor user sheep buying more RAM and decacore to get that crap rendered"
<DocScrutinizer05>
when you wanna eat the cheese, don't complain when it stinks
<Steven__>
The worst ones are the sites that you can't even render or navigate without half a dozen javascript sources allowed.
<DocScrutinizer05>
well, then simply never visit those
<Steven__>
And then you need another half a dozen if you want basic functionality from the website other than navigation.
<Steven__>
I try, but sometimes there is a particular reason to go to one.
<DocScrutinizer05>
those pages will exist and prosper as long and just as long as people are willing to get more RAm and faster CPU just to visit them
<Steven__>
I have been wondering for a while if it would be beneficial to have local versions of FLOSS JS libraries and then rewrite the references on the page to use the local copies.
<Steven__>
You would at least get some degree of security from that.