Index: trunk/doc-rnd/devlog/20162601.html =================================================================== --- trunk/doc-rnd/devlog/20162601.html (revision 1219) +++ trunk/doc-rnd/devlog/20162601.html (nonexistent) @@ -1,59 +0,0 @@ - - -

pcb-rnd devlog

- -

Burried/blind via poll

- -

Results

- -I received 10 full answers to the poll - thanks everyone who -answered. This is a small sample, but this is the best I could get -(I can't reach more pcb users). -

-Raw results are available in html, tsv and -csv format. - -

My interpretation

- -(User obviously means "those users who answered the poll") - -

1. only half of the users would consider even trying pcb-rnd for blind/burried vias -
2. there was only one user who'd consider switching to pcb-rnd for blind-burried vias - this feature doesn't seem to be valuable enough to attract users (details below) -
3. about half of the users need blind/burried via; when they do, they don't use pcb -
4. 9 out of 10 users runs PCB on Linux -

- -

My conclusions

-Because of 1. and 2., pcb-rnd doesn't seem to need blind/burried vias. The -purpose of question 7 was to find out whether users value this feature high -enough to actually consider investing time/effort in return, compared to -question 6. This pair of questions was designed to avoid noise that comes -from the fact that we, on the list tend to express our opinions in vast -crowds while only a few invest more time than talking and do actual work. -According to the result of line 7, my conclusion is that it's absolutely -not blind/burried vias that potential pcb-rnd users need. Thus -my decision is that I won't spend time on this feature in the near future. -

-The situation for pcb might be different, tho. I worded the first 4 questions -to find out how strong the need is among the users of mainline pcb and whether -they are devoted to pcb or choose the tool according to the design requirements. -There seems to be a correlation between having to use blind/burried vias -and using other layout tools. Or in other words: those who are happy with pcb -usually don't need or want blind/burried vias anyway and those who do have -already switched to another tool. -

-This suggests mainline pcb could benefit from burried/blind vias. However, -the demand is much lower than "every new design needs this" or "no new -user would consider pcb because of this missing feature". -

-Linux: it seems pcb power users mostly use Linux. I am not sure if it's -because PCB works well on Linux and is a bit harder to compile on -anything else - or the other way around (Linux users are more attracted -to PCB). - - - - - - Index: trunk/doc-rnd/devlog/20160126.html =================================================================== --- trunk/doc-rnd/devlog/20160126.html (nonexistent) +++ trunk/doc-rnd/devlog/20160126.html (revision 1220) @@ -0,0 +1,59 @@ + + +

pcb-rnd devlog

+ +

Burried/blind via poll

+ +

Results

+ +I received 10 full answers to the poll - thanks everyone who +answered. This is a small sample, but this is the best I could get +(I can't reach more pcb users). +

+Raw results are available in html, tsv and +csv format. + +

My interpretation

+ +(User obviously means "those users who answered the poll") + +

1. only half of the users would consider even trying pcb-rnd for blind/burried vias +
2. there was only one user who'd consider switching to pcb-rnd for blind-burried vias - this feature doesn't seem to be valuable enough to attract users (details below) +
3. about half of the users need blind/burried via; when they do, they don't use pcb +
4. 9 out of 10 users runs PCB on Linux +

+ +

My conclusions

+Because of 1. and 2., pcb-rnd doesn't seem to need blind/burried vias. The +purpose of question 7 was to find out whether users value this feature high +enough to actually consider investing time/effort in return, compared to +question 6. This pair of questions was designed to avoid noise that comes +from the fact that we, on the list tend to express our opinions in vast +crowds while only a few invest more time than talking and do actual work. +According to the result of line 7, my conclusion is that it's absolutely +not blind/burried vias that potential pcb-rnd users need. Thus +my decision is that I won't spend time on this feature in the near future. +

+The situation for pcb might be different, tho. I worded the first 4 questions +to find out how strong the need is among the users of mainline pcb and whether +they are devoted to pcb or choose the tool according to the design requirements. +There seems to be a correlation between having to use blind/burried vias +and using other layout tools. Or in other words: those who are happy with pcb +usually don't need or want blind/burried vias anyway and those who do have +already switched to another tool. +

+This suggests mainline pcb could benefit from burried/blind vias. However, +the demand is much lower than "every new design needs this" or "no new +user would consider pcb because of this missing feature". +

+Linux: it seems pcb power users mostly use Linux. I am not sure if it's +because PCB works well on Linux and is a bit harder to compile on +anything else - or the other way around (Linux users are more attracted +to PCB). + + + + + + Index: trunk/doc-rnd/devlog/20160316_unglib.html =================================================================== --- trunk/doc-rnd/devlog/20160316_unglib.html (nonexistent) +++ trunk/doc-rnd/devlog/20160316_unglib.html (revision 1220) @@ -0,0 +1,49 @@ + + +

pcb-rnd devlog

+ +

unglib: glib removal

+ +

glib problems

+ +As mentioned in a previous post, glib is +sometimes dangerous. Even if it was not, it's still huge and contradicts +the UNIX philosophy: Do One Thing and Do It Well. Glib tries to do a lot +of things. I do not doubt it is trying to do each of these things well, but as +a combination it's pretty much impossible to Keep It Simple, Stupid. +While glib is modular in design, from the viewpoint of an application it is +not modular: it's highly unlikely that the application can replace a part +of glib while keeping the rest. +

+The source of these problems is that glib is a "megalib" that tries to solve +a host of problems as a package. + +

The solution

+ +The solution is to replace the megalib with +a set of independent minilibs. Each minilib: +

tries to do one thing - e.g. linked lists, without coupling it with a custom memory allocator +
is simple - the API is so small that it's easy to learn it in minutes +
is small - so that if anything breaks it's very easy to find and fix the bug (when did you last debug internals of glib?) +
is replaceable - since they are independent, if one doesn't work up to expectations, it's real easy to replace it without affecting any other part; e.g. replacing linked lists without replacing hash tables +

+The minilibs are imported as svn externals in trunk/src_3rd. They are small +enough so that they can be distributed together with pcb sources. + +

Current state

+ +The "unglib" patch is mostly done. All references of glib are removed +from the core and the lesstif hid. There are a three components that +still depend on glib, but they each can be disabled: +

the GTK HID: because gtk is already coupled with glib, it doesn't make much sense to remove glib from the gtk HID code +
the toporouter plugin: the code is huge and will be potentially deprecated anyway (lack of developer resources/user interest) +
the puller: glib should be removed from the puller long term but the code is big and there's no much user need for it in pcb-rnd +

+This means pcb-rnd can be compiled with lesstif (or a compatible motif) +on a UNIX box without depending on glib. Together with the earlier effort +that removed autotools, it means a UNIX box without any "GNU infection" +should be able to compile and run pcb-rnd.