Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > pl.comp.programming > #27086 > unrolled thread
| Started by | Sebastian Biały <heby@poczta.onet.pl> |
|---|---|
| First post | 2015-07-24 11:12 +0200 |
| Last post | 2015-10-20 15:22 +0200 |
| Articles | 20 on this page of 211 — 19 participants |
Back to article view | Back to pl.comp.programming
[OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-07-24 11:12 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "Stachu 'Dozzie' K." <dozzie@go.eat.some.screws.spammer.invalid> - 2015-07-24 09:55 +0000
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-07-24 12:17 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> - 2015-07-24 12:31 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-07-24 12:42 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> - 2015-07-24 12:54 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Adam Klobukowski <adamklobukowski@gmail.com> - 2015-07-25 13:08 -0700
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-07-28 22:27 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Pit <nospam@sdf.lonestar.org> - 2015-07-28 21:11 +0000
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Pit <nospam@sdf.lonestar.org> - 2015-07-29 02:15 +0000
Re: [OT] Duża kasa i kiepski wynik - dlaczego? szemrany <szemrany@offline.off> - 2015-07-30 20:40 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Pit <nospam@sdf.lonestar.org> - 2015-07-30 20:16 +0000
Re: [OT] Duża kasa i kiepski wynik - dlaczego? szemrany <szemrany@offline.off> - 2015-07-31 18:11 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> - 2015-08-03 08:39 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Roman W <bloody_rabbitREMOVETHIS@gazeta.pl> - 2015-08-02 03:09 +0100
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> - 2015-08-03 08:34 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Budzik <budzik61@poczta.o.n.e.t.pl.nie.spam.oj> - 2015-08-04 07:00 +0000
Re: [OT] Duża kasa i kiepski wynik - dlaczego? szemrany <szemrany@offline.off> - 2015-08-04 17:09 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> - 2015-08-05 07:39 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? RW <bloody_rabbit@gazeta.pl> - 2015-08-05 07:42 +0100
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> - 2015-08-05 09:40 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? szemrany <szemrany@offline.off> - 2015-09-30 13:38 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Roman W <bloody_rabbitREMOVETHIS@gazeta.pl> - 2015-07-30 12:33 +0100
Re: [OT] Duża kasa i kiepski wynik - dlaczego? szemrany <szemrany@offline.off> - 2015-07-30 16:28 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Pit <nospam@sdf.lonestar.org> - 2015-07-30 15:25 +0000
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Roman W <bloody_rabbitREMOVETHIS@gazeta.pl> - 2015-07-30 21:32 +0100
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-09 14:27 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-09 20:10 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-10 19:55 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-10 21:16 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-10 23:20 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-11 21:33 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-12 12:18 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-12 14:19 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-12 14:43 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-12 17:18 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-12 19:26 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-12 20:28 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-12 22:35 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-13 11:54 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Roman W <bloody_rabbitREMOVETHIS@gazeta.pl> - 2015-09-14 00:37 +0100
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-14 10:16 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? RW <bloody_rabbit@gazeta.pl> - 2015-09-15 20:30 +0100
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-16 10:48 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Roman W <bloody_rabbitREMOVETHIS@gazeta.pl> - 2015-09-17 20:47 +0100
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-12 15:08 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-12 17:39 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-12 19:59 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-12 21:13 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-13 11:02 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-13 11:57 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-13 13:14 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-13 13:53 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-13 15:15 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-13 17:33 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? szemrany <szemrany@offline.off> - 2015-09-13 17:57 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-13 18:04 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? szemrany <szemrany@offline.off> - 2015-09-13 18:21 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-13 18:50 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? szemrany <szemrany@offline.off> - 2015-09-13 19:51 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-13 20:01 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? grapeli23 <grapeli23@googlemail.com> - 2015-09-13 18:17 +0000
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-13 20:22 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? grapeli23 <grapeli23@googlemail.com> - 2015-09-13 18:47 +0000
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-13 21:10 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-13 21:15 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? grapeli23 <grapeli23@googlemail.com> - 2015-09-13 19:28 +0000
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-13 21:34 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-13 21:36 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> - 2015-09-14 10:42 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-13 20:23 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-13 20:35 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-13 20:39 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-13 20:58 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-13 21:12 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-13 21:23 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-13 21:34 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-13 21:37 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-13 21:42 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-14 14:05 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? szemrany <szemrany@offline.off> - 2015-09-15 22:11 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-16 11:40 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? szemrany <szemrany@offline.off> - 2015-09-16 16:08 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-16 17:15 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> - 2015-09-17 07:47 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-17 16:47 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> - 2015-09-18 07:25 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? szemrany <szemrany@offline.off> - 2015-09-17 20:46 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? szemrany <szemrany@offline.off> - 2015-09-18 08:41 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "Radoslaw Szwed" <radekszwed@pochta.fm> - 2015-09-16 14:06 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? wloochacz <wloochacz@no.spam.gmail.com> - 2015-09-16 20:19 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "re" <re@re.invalid> - 2015-09-24 20:55 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-24 23:05 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-13 20:11 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-13 20:35 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-13 20:53 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-13 20:54 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-13 21:17 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-13 21:29 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-13 21:45 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-13 21:50 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-13 22:01 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-13 22:22 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Marek Borowski <marek@nazwisko.com> - 2015-09-14 13:05 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-14 13:14 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "re" <re@re.invalid> - 2015-09-24 21:25 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-24 23:09 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "re" <re@re.invalid> - 2015-09-24 21:13 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-24 23:09 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "re" <re@re.invalid> - 2015-09-24 21:11 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-24 23:15 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> - 2015-09-14 10:31 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? szemrany <szemrany@offline.off> - 2015-09-14 11:16 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Roman W <bloody_rabbitREMOVETHIS@gazeta.pl> - 2015-09-17 00:52 +0100
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Roman W <bloody_rabbitREMOVETHIS@gazeta.pl> - 2015-09-17 00:50 +0100
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-12 15:36 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-12 17:54 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-12 20:35 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-12 21:46 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-13 11:30 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-13 12:13 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-13 11:34 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-13 12:22 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-13 13:30 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-13 13:58 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-13 14:54 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Marek Borowski <marek@nazwisko.com> - 2015-09-13 21:50 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-13 22:07 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-13 22:24 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-12 12:56 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-12 14:45 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-12 15:12 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-12 17:02 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-12 17:41 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-12 18:10 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-12 21:02 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-12 21:30 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-13 11:29 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-13 12:11 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? szemrany <szemrany@offline.off> - 2015-09-13 12:14 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-13 14:22 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-13 17:21 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-12 15:58 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-12 17:04 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-12 18:17 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-12 19:45 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-12 21:59 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-12 22:22 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-13 12:05 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-13 12:53 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-13 14:08 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-13 14:18 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-13 15:25 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-13 17:54 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-13 20:15 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-13 20:44 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-13 21:00 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Roman W <bloody_rabbitREMOVETHIS@gazeta.pl> - 2015-09-17 00:57 +0100
Re: [OT] Du?a kasa i kiepski wynik - dlaczego? Waldek Hebisch <antyspam@math.uni.wroc.pl> - 2015-09-13 00:11 +0000
Re: [OT] Du?a kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-13 11:57 +0200
Re: [OT] Du?a kasa i kiepski wynik - dlaczego? Waldek Hebisch <hebisch@math.uni.wroc.pl> - 2015-09-14 02:02 +0000
Re: [OT] Du?a kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-14 10:54 +0200
Re: [OT] Du?a kasa i kiepski wynik - dlaczego? Waldek Hebisch <antyspam@math.uni.wroc.pl> - 2015-09-14 15:00 +0000
Re: [OT] Du?a kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-14 17:40 +0200
Re: [OT] Du?a kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-13 14:07 +0200
Re: [OT] Du?a kasa i kiepski wynik - dlaczego? Waldek Hebisch <antyspam@math.uni.wroc.pl> - 2015-09-13 19:14 +0000
Re: [OT] Du?a kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-13 21:58 +0200
Re: [OT] Du?a kasa i kiepski wynik - dlaczego? Waldek Hebisch <hebisch@math.uni.wroc.pl> - 2015-09-14 00:53 +0000
Re: [OT] Du?a kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-14 10:38 +0200
Re: [OT] Du?a kasa i kiepski wynik - dlaczego? Waldek Hebisch <hebisch@math.uni.wroc.pl> - 2015-09-14 19:51 +0000
Re: [OT] Du?a kasa i kiepski wynik - dlaczego? Roman W <bloody_rabbitREMOVETHIS@gazeta.pl> - 2015-09-17 00:56 +0100
Re: [OT] Du?a kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-17 06:30 +0200
Re: [OT] Du?a kasa i kiepski wynik - dlaczego? Roman W <bloody_rabbitREMOVETHIS@gazeta.pl> - 2015-09-19 16:30 +0100
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "Stachu 'Dozzie' K." <dozzie@go.eat.some.screws.spammer.invalid> - 2015-09-14 10:31 +0000
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "M.M." <mmarszik@gmail.com> - 2015-09-12 08:31 -0700
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-12 19:09 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-12 19:24 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "AK" <nobody@nowhere.com> - 2015-09-12 21:25 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-12 21:50 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Roman W <bloody_rabbitREMOVETHIS@gazeta.pl> - 2015-09-17 00:47 +0100
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> - 2015-09-14 08:56 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-09-14 18:03 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "Stachu 'Dozzie' K." <dozzie@go.eat.some.screws.spammer.invalid> - 2015-07-24 10:57 +0000
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-07-24 13:05 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "Stachu 'Dozzie' K." <dozzie@go.eat.some.screws.spammer.invalid> - 2015-07-24 12:03 +0000
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-07-24 15:13 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "Stachu 'Dozzie' K." <dozzie@go.eat.some.screws.spammer.invalid> - 2015-07-24 13:41 +0000
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> - 2015-07-24 12:25 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-07-24 12:30 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> - 2015-07-24 12:37 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-07-24 12:47 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> - 2015-07-29 10:50 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "M.M." <mmarszik@gmail.com> - 2015-07-29 02:07 -0700
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "Stachu 'Dozzie' K." <dozzie@go.eat.some.screws.spammer.invalid> - 2015-07-29 09:13 +0000
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "M.M." <mmarszik@gmail.com> - 2015-07-29 02:36 -0700
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "Stachu 'Dozzie' K." <dozzie@go.eat.some.screws.spammer.invalid> - 2015-07-29 09:50 +0000
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "M.M." <mmarszik@gmail.com> - 2015-07-29 03:00 -0700
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Piotr Chamera <piotr_chamera@poczta.onet.pl> - 2015-07-29 12:10 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "M.M." <mmarszik@gmail.com> - 2015-07-29 03:35 -0700
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Pit <nospam@sdf.lonestar.org> - 2015-07-29 19:22 +0000
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Budzik <budzik61@poczta.o.n.e.t.pl.nie.spam.oj> - 2015-07-30 16:00 +0000
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Budzik <budzik61@poczta.o.n.e.t.pl.nie.spam.oj> - 2015-07-31 17:00 +0000
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> - 2015-08-03 08:43 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? "M.M." <mmarszik@gmail.com> - 2015-07-30 12:26 -0700
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Adam Klobukowski <adamklobukowski@gmail.com> - 2015-07-24 03:33 -0700
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-07-24 12:48 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Adam Klobukowski <adamklobukowski@gmail.com> - 2015-07-24 06:43 -0700
Re: [OT] Duża kasa i kiepski wynik - dlaczego? szemrany <szemrany@offline.off> - 2015-10-14 21:53 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? Sebastian Biały <heby@poczta.onet.pl> - 2015-10-15 19:01 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? szemrany <szemrany@offline.off> - 2015-10-15 23:29 +0200
Re: [OT] Duża kasa i kiepski wynik - dlaczego? szemrany <szemrany@offline.off> - 2015-10-20 15:22 +0200
Page 1 of 11 [1] 2 3 … 11 Next page →
| From | Sebastian Biały <heby@poczta.onet.pl> |
|---|---|
| Date | 2015-07-24 11:12 +0200 |
| Subject | [OT] Duża kasa i kiepski wynik - dlaczego? |
| Message-ID | <mosvh7$bpl$1@node1.news.atman.pl> |
Obudził mnie dzisiaj rano nowy problemik w naszym ukochanym kraju: http://tinyurl.com/pb3xgax W skrócie: a) tworzymy jakąs baze danych (raczej prymitywną) b) wydajemy na to dziesiątki/setki mln zlotych c) system jest spieprzony i wchodzi na produkcje bez testów d) chcemy więcej kasy na zrobnienie szyny (wtf?) Czyli dzień jak codzień w dużych kontraktach informatycznych. Ale ja nie o tym. Moje pytanie jest następujące: co w tym systemie kosztuje dziesiątki (a chyba obecnie już setki) mln złotych? Nie mówcie że przejadają je debile w krawatach na bankietach biznesowych. Patrze na to z perspektywy programisty i najzwyczajniej w świecie nie mam pojecia jak na przestrzeni kilkudziesięciu miesiecy upchnąć setki mln złotych w proces tworzenia gównianej bazy danych. Nawet jesli zakłada to dodatkowy wydatek na sprzęt, budynek, whatever. Na co idzie taka kasa? Ma ktoś doświadczenia w pracy z takimi projketami i może wie gdzie jest ta czarna dziura? Takich projektów było wiele wliczając w to CEPIK i podobne. To jest kompletna abstrakcja w stosunku możliwości-jakość / cena. Jak to można uzasadnić technicznie? Najwyczajniej zastanawia mnie gdzie się podziały moje podatki :/ W sensie tym razem *inżynierskim*.
[toc] | [next] | [standalone]
| From | "Stachu 'Dozzie' K." <dozzie@go.eat.some.screws.spammer.invalid> |
|---|---|
| Date | 2015-07-24 09:55 +0000 |
| Message-ID | <slrnmr433s.9q8.dozzie@jarowit.net> |
| In reply to | #27086 |
On 2015-07-24, Sebastian Biały <heby@poczta.onet.pl> wrote: > Obudził mnie dzisiaj rano nowy problemik w naszym ukochanym kraju: > > http://tinyurl.com/pb3xgax > > W skrócie: > a) tworzymy jakąs baze danych (raczej prymitywną) > b) wydajemy na to dziesiątki/setki mln zlotych > c) system jest spieprzony i wchodzi na produkcje bez testów > d) chcemy więcej kasy na zrobnienie szyny (wtf?) > > Czyli dzień jak codzień w dużych kontraktach informatycznych. Ale ja nie > o tym. > > Moje pytanie jest następujące: co w tym systemie kosztuje dziesiątki (a > chyba obecnie już setki) mln złotych? Nie mówcie że przejadają je debile > w krawatach na bankietach biznesowych. Patrze na to z perspektywy > programisty i najzwyczajniej w świecie nie mam pojecia jak na > przestrzeni kilkudziesięciu miesiecy upchnąć setki mln złotych w proces > tworzenia gównianej bazy danych. Oligopol. Zamówień publicznych na skalę ogólnopolską nie realizują małe podmioty (choćby z tytułu wadium przy przetargu), a z dużych podmiotów (których jest niewiele) tylko niektóre się zabierają za zadania z tego sektora, co jeszcze bardziej zawęża listę graczy. > Nawet jesli zakłada to dodatkowy > wydatek na sprzęt, budynek, whatever. Na co idzie taka kasa? Ma ktoś > doświadczenia w pracy z takimi projketami i może wie gdzie jest ta > czarna dziura? Takich projektów było wiele wliczając w to CEPIK i > podobne. To jest kompletna abstrakcja w stosunku możliwości-jakość / > cena. Jak to można uzasadnić technicznie? Błąd. Tego się nie uzasadnia technicznie, to się uzasadnia ekonomicznie. -- Secunia non olet. Stanislaw Klekot
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Biały <heby@poczta.onet.pl> |
|---|---|
| Date | 2015-07-24 12:17 +0200 |
| Message-ID | <mot3b3$fmd$1@node1.news.atman.pl> |
| In reply to | #27087 |
On 2015-07-24 11:55, Stachu 'Dozzie' K. wrote: > Błąd. Tego się nie uzasadnia technicznie To jest zagadnienie 100% techniczne, w dodatku fizyczna infrastruktura jest ułamkiem kosztów, zdecydowanie więcej jest pracy z częscią wirtualną (kodem, bazą). Powiedzmy że mamy 100mln zlotych. 20 wydajemy na budynek + hardware + licencje (zakładam że to nie bedzie biegać na MySQLu, choć kto wie ...). Pozostaje 80mln. To musi byc koszt pracy programistów i managmentu, wdrożeń i testów. Ale jak u diabła można wydać 80mln na te zadania? Brak uzasadnienia technicznego kosztów skłania mnie jednak do tego że gro tych kosztów przejadają debile w krawatach. Szukam więc jakiegoś kontrargumentu, typu "programista COBOLa to 1mln/mieś" czy coś. Coś co da złudzenie zasadności. Pytam bo chcę wiedzieć jakie problemy techniczne napotyka firma chcąca zrobić bazę danych tego typu. Wydaje mi się w swojej ignorancji że to raczej nie jest skomplikowana baza danych. Z wiekszych ficzerów zapewne ma umożliwić data mining i to tyle. Co jest problemem inzynierskim w stworzeniu jej? Czemu nie podoła firma zatrudniająca ze 3 doświadczonych projektantów za 5mln?
[toc] | [prev] | [next] | [standalone]
| From | Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> |
|---|---|
| Date | 2015-07-24 12:31 +0200 |
| Message-ID | <55b2141b$0$2206$65785112@news.neostrada.pl> |
| In reply to | #27088 |
W dniu 2015-07-24 12:17, Sebastian Biały pisze: > On 2015-07-24 11:55, Stachu 'Dozzie' K. wrote: >> Błąd. Tego się nie uzasadnia technicznie > > To jest zagadnienie 100% techniczne, w dodatku fizyczna infrastruktura > jest ułamkiem kosztów, zdecydowanie więcej jest pracy z częscią > wirtualną (kodem, bazą). Powiedzmy że mamy 100mln zlotych. 20 wydajemy > na budynek + hardware + licencje (zakładam że to nie bedzie biegać na > MySQLu, choć kto wie ...). Pozostaje 80mln. To musi byc koszt pracy > programistów i managmentu, wdrożeń i testów. Ale jak u diabła można > wydać 80mln na te zadania? Bazę o takich rozmiarach w mysql-u? Dowcip? > > Brak uzasadnienia technicznego kosztów skłania mnie jednak do tego że > gro tych kosztów przejadają debile w krawatach. Szukam więc jakiegoś > kontrargumentu, typu "programista COBOLa to 1mln/mieś" czy coś. Coś co > da złudzenie zasadności. > > Pytam bo chcę wiedzieć jakie problemy techniczne napotyka firma chcąca > zrobić bazę danych tego typu. Wydaje mi się w swojej ignorancji że to > raczej nie jest skomplikowana baza danych. Z wiekszych ficzerów zapewne > ma umożliwić data mining i to tyle. Co jest problemem inzynierskim w > stworzeniu jej? Czemu nie podoła firma zatrudniająca ze 3 doświadczonych > projektantów za 5mln? Nie wiem jakie są założenia projektu - choćby to jakie obciążenie jest spodziewane (na czym m.innymi wyłożyli się twórcy systemu wyborczego - bo w sumie dużo komisji nie było, tylko, że ok 90% z nich próbowało się dobić do bazy w ciągu tej samej godziny, a brak doświadczenia w tworzeniu baz wyszedł, że dane się rozeszły (prawdopodobnie źle zaprojektowane transakcje).... obawiam się, że 3 projektantów może być za mało, by stworzyć całość w ciągu powiedzmy roku. A tu dochodzi jeszcze problem, że urzędnicy nie potrafili zdefiniować dokładnie jak ma to działać. -- Kaczus http://kaczus.ppa.pl
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Biały <heby@poczta.onet.pl> |
|---|---|
| Date | 2015-07-24 12:42 +0200 |
| Message-ID | <mot4ri$v0v$1@node2.news.atman.pl> |
| In reply to | #27091 |
On 2015-07-24 12:31, Tomasz Kaczanowski wrote: > Bazę o takich rozmiarach w mysql-u? Dowcip? Tak to dowcip. Przy czym wcale się nie zdziwie jak zostanie wdrożony. Ogólnie zyjemy w wesołym kraju a najtańsi programisci znają tylko MySQLa. > Nie wiem jakie są założenia projektu - choćby to jakie obciążenie jest > spodziewane (na czym m.innymi wyłożyli się twórcy systemu wyborczego - > bo w sumie dużo komisji nie było, tylko, że ok 90% z nich próbowało się > dobić do bazy w ciągu tej samej godziny, a brak doświadczenia w > tworzeniu baz wyszedł, że dane się rozeszły (prawdopodobnie źle > zaprojektowane transakcje) Zatrudnili ludzi z miernym doświadczeniem. Zakładam że za 1mln/rok mozna zatrunić kogoś z niezłym. Ponadto w *TYM* przypadku nie ma mowy o kumulacji zapytań - obciążenia bedzie mniej więcej stałe chyba że 40mln osob pojawi się nagle w przychodni ze sraczką. To się *raczej* nie trafi. Problemy z obciążeniem tego projektu raczej nie dotyczą - bo można je przewidzieć. >.... obawiam się, że 3 projektantów może być > za mało, by stworzyć całość w ciągu powiedzmy roku. To niech ich będzie 10. Dalej trzeba uzasadnić wsiąknięcie 100mln złotych w przeciętny projekt. > A tu dochodzi > jeszcze problem, że urzędnicy nie potrafili zdefiniować dokładnie jak ma > to działać. Tego typu brak kompetencji nie generuje kosztów idących w setki mln. Znaczna częśc projektów informatycznych pracuje w warunkach niestabilnych specyfikacji i od dawna potafimy sobie z tym wydaje radzić. To tylko wymówko-dupochron.
[toc] | [prev] | [next] | [standalone]
| From | Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> |
|---|---|
| Date | 2015-07-24 12:54 +0200 |
| Message-ID | <55b21984$0$8386$65785112@news.neostrada.pl> |
| In reply to | #27094 |
W dniu 2015-07-24 12:42, Sebastian Biały pisze: >> Nie wiem jakie są założenia projektu - choćby to jakie obciążenie jest >> spodziewane (na czym m.innymi wyłożyli się twórcy systemu wyborczego - >> bo w sumie dużo komisji nie było, tylko, że ok 90% z nich próbowało się >> dobić do bazy w ciągu tej samej godziny, a brak doświadczenia w >> tworzeniu baz wyszedł, że dane się rozeszły (prawdopodobnie źle >> zaprojektowane transakcje) > > Zatrudnili ludzi z miernym doświadczeniem. Zakładam że za 1mln/rok mozna > zatrunić kogoś z niezłym. Ale oni na wszystko - włącznie z wdrożeniem chyba coś ok pół miliona dostali - tu jest problem. > Ponadto w *TYM* przypadku nie ma mowy o kumulacji zapytań - obciążenia > bedzie mniej więcej stałe chyba że 40mln osob pojawi się nagle w > przychodni ze sraczką. To się *raczej* nie trafi. Problemy z obciążeniem > tego projektu raczej nie dotyczą - bo można je przewidzieć. Zależy co ma wykonywac system - jak mniemam, ma potwierdzać ubezpieczenie, zapisywać jakieś dane o pacjencie, informować o zakupach leków na receptę - tego mogę się domyślać, a ile rzeczy będzie rzeczywiście do przesłania w tę czy we wte tego nie wiem. >> A tu dochodzi >> jeszcze problem, że urzędnicy nie potrafili zdefiniować dokładnie jak ma >> to działać. > > Tego typu brak kompetencji nie generuje kosztów idących w setki mln. > Znaczna częśc projektów informatycznych pracuje w warunkach > niestabilnych specyfikacji i od dawna potafimy sobie z tym wydaje > radzić. To tylko wymówko-dupochron. > Tak generuje - z czym się nie raz spotkaliśmy startując też w przetargach - jak dochodziło do szczegółowych zapytań to nagle budżet rósł, bo ktoś sobie wymyślił, ze ma coś być danej klasy i działać np pod systemem qnx-a - wszystko ładnie, ale dobranie do tego jednego elementu danej klasy reszty elementów powoduje, ze nagle cena serwera wzrasta dwukrotnie inaczej nie zadziała. To tylko jeden z przykładów. Druga rzecz, że projekty unijne potrzebują dodatkowej biurokracji i dodatkowych papierów, ze już nie wspomnę o ofertach w jednej ustalonej walucie, żeby można było porównywać - tylko wtedy cena idzie w górę, bo oferta ma być obowiązująca za 2-3 miesiące - wiec nikt nie zaryzykuje - jeśli są to rzeczy niestandardowe nie brać ryzyka zmiany kursu i umieszczenia tego w cenie. Dodatkowo właśnie funkcjonalność, która zmieni się w trakcie prac - co jest prawie pewne. I jak napisałem, nie sadzę, by koszty były tego rzędu - ale też nie minimalizowałbym z drugiej strony za bardzo - właśnie dlatego, że jak napisałem - niekompetencja urzędnicza jest często dość duża. -- Kaczus http://kaczus.cba.pl
[toc] | [prev] | [next] | [standalone]
| From | Adam Klobukowski <adamklobukowski@gmail.com> |
|---|---|
| Date | 2015-07-25 13:08 -0700 |
| Message-ID | <991b8162-a09e-4ef3-b58f-6af678a319d4@googlegroups.com> |
| In reply to | #27091 |
W dniu piątek, 24 lipca 2015 23:15:54 UTC+2 użytkownik grapeli23 napisał: > Dnia 24.07.2015 Pit <nospam@sdf.lonestar.org> napisał/a: > > > > Skoro Wikipedia daje radę na mySQL-u to czemu nie baza danych z kartami > > pacjentów? > > Taki niepozorny serwis jak YouTube również w znaczący sposób korzysta z > MySQL. > > https://github.com/youtube/vitess To jest kwestia supportu. Youtube czy Wikipedia taki support zapewniają sobie same, ponadto, nie jest dla nich problemem upgrade. System dla ministerstwa zdrowia nie będzie miał własnego supportu (w formie developerów), w związku z czym musi opierać się na oprogramowaniu którego okres supportu (i wypuszczania patchy) liczy się w dziesiątkach lat, a to aktualnie zapewniają tylko rozwiązania komercyjne. AdamK
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Biały <heby@poczta.onet.pl> |
|---|---|
| Date | 2015-07-28 22:27 +0200 |
| Message-ID | <mp8okc$8sf$1@node2.news.atman.pl> |
| In reply to | #27117 |
On 2015-07-27 23:14, Pit wrote: >> To jest niemożliwe albo oparte o systemy odlewane ze zbrojonego betonu. > Koszt zapoznania się z nieznanym systemem, zrozumienia jego funkcjonowania > itp. może przekroczyć koszty napisania odpowiednika od zera. Wynika to z faktu że podstawowa metoda refaktoringu softu rzadowego to poczekanie aż umrą/wyemigrują wszyscy ktorzy się tym zajmowali a nastepnie przez 10 lat pisanie nastepnego identycznego w warunkach "rany boskie na kiedy będzie?". > Mimo że masz > źródła, to i tak to jest praktycznie reverse engineering (jeśli nie masz do > tego dobrej dokumentacji). Wystarczyło by zatrudnić kilku ludzi do matience i uzupełniania ficzerami w sposób ciągły. Wyszło by taniej niż pisanie od nowa. Ba, mogło by się okazać że pisanie od nowa bylo by zbędne. Z jakiejś przyczyny jednak polityco oczekują "raz a dobrze" co kończy się jak cepik i okolice. > Bo "ficzer" to nie zawsze jest banalna sprawa, nawet jeśli system jest > bardzo elastycznie zaprojektowany. Często to jest coś w rodzaju "dołóżcie > możliwość tankowania diesla benzyną". Dzień jak codzień w scrumach. Teamy scrumowe czasem robią duże projekty (na kilkadziesiąt lat rozwoju i utrzymania). > Nie dalej jak rok temu została wyłączona ostatnia Odra pracująca na kolei > (nie pamiętam już gdzie). Skoro coś działa bezawaryjnie i wystarczająco dobrze, Twoje wystaczająco dobrze to typowy dziadowski kompromis. Efketem tego "wystarczająco dobrze" jest system rezerwacji na kolei który pisany przez idotę nie zakładał że mozna w nazwisku podać # co powoduje niemożnośc kontroli bilteów w całym składzie jeśli jeden pasażer zatroluje takim znakiem w rezerwacji elektronicznej. Witamy w świecie "wystarczająco dobrze". http://tinyurl.com/ndsn67q Podobno naprawili. Bo wszystko da się naprawić. Ostatnio poleciała głowa jakiegoś szefa informatyki na tej smiejszej instytucji rownież z powodu "działa to nie ruszać". I przestało. > Skoro Odra miała wystarczającą wydajność obliczeniową Nie miała. Nazwyczajniej w świecie nie dawało się jej nowych tasków bo by sie przekręciła. Twoje "wystarczająco" zakłada brak rozwoju. Tak samo mysleli mistrzowie od Elixiru. Efektem dzisiaj mamy co najmniej idiotyczny system rozliczen międzybankowych gdzie przelewy nosi się chyba w wiadrach między komputerami sądząc po czasach. > , pojemność pamięci, Nie miała. Stosowano sztuczki pozwalające na zmieszczenie się w tym co było. Czyli programowanie przez workaroundy i ograniczanie specyfikacji. > wygodę obsługi Żartujesz prawda? > i bezawaryjność Hardwareowa zbliżała się do granicy rozpadu krzemu na kwarki i wypadnięcia koralików z pamięci. Części zamienne w kilku muzeach były ale diabli wiedzą czy sprawne. 20 lat temu sam przyczyniłem sie do rozebrania, poprzez rozlutowanie na warsztatach szkolnych, jednej sztuki. Nie wiem czy bym chciał aby pracowała do dzisiaj - jakość montażu była tragiczna. > (a przez tyle lat pracy wyeliminowano z > systemu praktycznie wszystkie błędy), to po co to zmieniać na coś nowego? Bo jak pewnego dnia zejdzie operator na zawał to pociągi staną. Nie ma nikogo w zastępstwie. Koniec. > dokładnie taki sam sens jak ładowanie 8-rdzeniowego Intela do sterowania > pralką automatyczną? Do pralek laduje się ARMy chodzące po kilkaset MHz. Nie dlatego że trzeba, tylko dlatego że ładowanie tam 8051 mija się z celem - ostatni programiści na ten badziew właśnie piszą testament. >> PS. Tak wiem że systemy obrony/ataku nuklearnego w USA obsługuje się >> dyskietkami 8" i nie zamierzają tego zmienić. > > Bez przesady, są stosowane dyski wymienne, bo do dysku wyjętego nie można > się włamać, a przy okazji są pozabezpieczane przed EMP, pożarem, zalaniem > itp. (są odporniejsze niż czarne skrzynki w samolotach). Nie. To zwykłe floppy 8": http://tinyurl.com/n8slnut
[toc] | [prev] | [next] | [standalone]
| From | Pit <nospam@sdf.lonestar.org> |
|---|---|
| Date | 2015-07-28 21:11 +0000 |
| Message-ID | <slrnmrfrv7.25v.nospam@nc10.lan> |
| In reply to | #27131 |
Dnia 28.07.2015 Sebastian Biały <heby@poczta.onet.pl> napisał/a: > Twoje wystaczająco dobrze to typowy dziadowski kompromis. Efketem tego > "wystarczająco dobrze" jest system rezerwacji na kolei który pisany > przez idotę nie zakładał że mozna w nazwisku podać # co powoduje > niemożnośc kontroli bilteów w całym składzie jeśli jeden pasażer > zatroluje takim znakiem w rezerwacji elektronicznej. Witamy w świecie > "wystarczająco dobrze". Nie, na tej Odrze nie chodziły systemy rezerwacji InterCity :D >> Skoro Odra miała wystarczającą wydajność obliczeniową > > Nie miała. Nazwyczajniej w świecie nie dawało się jej nowych tasków bo > by sie przekręciła. Twoje "wystarczająco" zakłada brak rozwoju. Owszem, Odry zajmowały się optymalizacją składów towarowych, stacje rozrządowe mają swoją ograniczoną pojemność i przepustowość. Co z tego że zwykły pecet przeliczy milion wagonów na minutę skoro stacja obsługuje maksymalnie kilkaset na dobę? > Tak samo > mysleli mistrzowie od Elixiru. Efektem dzisiaj mamy co najmniej > idiotyczny system rozliczen międzybankowych gdzie przelewy nosi się > chyba w wiadrach między komputerami sądząc po czasach. Są różne systemy rozliczeń międzybankowych, Elixir jest tylko jednym z nich, jest powszechny i tani (zwykle bezpłatny) a szybkość działania jest wystarczająca dla przeciętnego Kowalskiego (i tak są szybkie w porównaniu do systemów "konsumenckich" w innych krajach), gdy potrzeba szybkiego przelewu, to się robi SORBNET (w większości banków płatny) i pieniądze są księgowane w kilka minut pomiędzy dwoma różnymi bankami. >> , pojemność pamięci, > > Nie miała. Stosowano sztuczki pozwalające na zmieszczenie się w tym co > było. Czyli programowanie przez workaroundy i ograniczanie specyfikacji. Pierwsze słyszę :D >> wygodę obsługi > > Żartujesz prawda? Nie, nie żartuję, pracownicy obsługujący system uważali go sa prosty i pragmatyczny (bez zbędnych bajerów). >> i bezawaryjność > > Hardwareowa zbliżała się do granicy rozpadu krzemu na kwarki i > wypadnięcia koralików z pamięci. Części zamienne w kilku muzeach były > ale diabli wiedzą czy sprawne. 20 lat temu sam przyczyniłem sie do > rozebrania, poprzez rozlutowanie na warsztatach szkolnych, jednej > sztuki. Nie wiem czy bym chciał aby pracowała do dzisiaj - jakość > montażu była tragiczna. Mimo wszystko pracowały kilkadziesiąt lat, obecny czas życia serwera to kilka lat. > Bo jak pewnego dnia zejdzie operator na zawał to pociągi staną. Nie ma > nikogo w zastępstwie. Koniec. I co to ma wspólnego z Odrą? Jeśli analogiczny system postawisz na chmurze Amazona i wyszkolisz w jego obsłudze jednego operatora, to jak zejdzie, to też "pociągi staną". >> dokładnie taki sam sens jak ładowanie 8-rdzeniowego Intela do sterowania >> pralką automatyczną? > > Do pralek laduje się ARMy chodzące po kilkaset MHz. Nie dlatego że > trzeba, tylko dlatego że ładowanie tam 8051 mija się z celem - ostatni > programiści na ten badziew właśnie piszą testament. Te z którymi ja miałem do czynienia (Amica, Samsung, Siemens) nie miały ARM-ów po kilkaset MHz tylko 8-bitowe kontrolery po kilkanaście MHz (najczęściej FreeScale). Oczywiście są modele z "bajerami" typu wbudowany tablet, ale mówię o typowych modelach. 8051 to oczywiście zabytek i projektowanie NOWEGO systemu na czymś takim jest bez sensu ale wiele już działających systemów będzie jeszcze działać przez lata. Co do "ostatni programiści na ten badziew piszą właśnie testament" - C to C, piny I/O to piny I/O, nie ma w tym jakiejś wielkiej filozofii, jeśli ktoś jest obyty z mikrokontrolerami, to sobie poradzi bez problemu. Nie trzeba do byle czego bawić się w stawianie kernela Linuxa na ARM-ie, wbrew pozorom to nie upraszcza prostych projektów (typu pralka) tylko je komplikuje. >>> PS. Tak wiem że systemy obrony/ataku nuklearnego w USA obsługuje się >>> dyskietkami 8" i nie zamierzają tego zmienić. >> >> Bez przesady, są stosowane dyski wymienne, bo do dysku wyjętego nie można >> się włamać, a przy okazji są pozabezpieczane przed EMP, pożarem, zalaniem >> itp. (są odporniejsze niż czarne skrzynki w samolotach). > > Nie. To zwykłe floppy 8": > > http://tinyurl.com/n8slnut No w rakietach z lat 70-tych ubiegłego wieku owszem tak, ale zostało ich już tylko około 500 sztuk.
[toc] | [prev] | [next] | [standalone]
| From | Pit <nospam@sdf.lonestar.org> |
|---|---|
| Date | 2015-07-29 02:15 +0000 |
| Message-ID | <slrnmrgdpp.29o.nospam@nc10.lan> |
| In reply to | #27132 |
Dnia 28.07.2015 szemrany <szemrany@offline.off> napisał/a:
> To z tego, że Odra miała fatalny współczynnik wydajności na wat oraz była
> trudna w konserwacji.
Jak ktoś ma swoje zakłady energetyczne, to się "watami" aż tak bardzo nie
przejmuje. Nie twierdzę, że TERAZ bym coś na Odrze wdrażał, ale zmieniać
dla samej zmiany to też bezsens (moim zdaniem oczywiście).
>> Są różne systemy rozliczeń międzybankowych, Elixir jest tylko jednym z
>> nich, jest powszechny i tani (zwykle bezpłatny) a szybkość działania jest
>> wystarczająca dla przeciętnego Kowalskiego (i tak są szybkie w porównaniu
>> do systemów "konsumenckich" w innych krajach), gdy potrzeba szybkiego
>> przelewu, to się robi SORBNET (w większości banków płatny) i pieniądze są
>> księgowane w kilka minut pomiędzy dwoma różnymi bankami.
>
> A co stoi na przeszkodzie by to się odbywało online i za darmo? Czemu musi
> trwać wieki lub kosztować? Są jakieś techniczne problemy z tym?
> I skąd przekonanie o braku potrzeby szybkiego przelewu u Kowalskiego? Gdyby
> to była prawda nie istniałyby BlueCashe, Przelewy24, DotPaye, PayPale,
> Transferuje, Payu, zPay, PayByNet, ePrzelerwy, YetiPay i pewnie jeszcze
> jakieś. Zgodzisz się?
Elixir powstał w czasach, kiedy internetów (zwłaszcza domowych) nie było,
był przystosowany do komunikacji protokołem X.25 (zwykłe modemy
telefoniczne i połączenie dial-up a nie stałe łącze) a także do
przenoszenia informacji off-line (na przykład na dyskietce) - w początkach
lat 90-tych (gdy powstawał) było to jak najbardziej słuszne założenie, bo
internet w takim rozumieniu jaki mamy dzisiaj, po prostu nie istniał w
świecie komercyjnym (istniał głównie w ośrodkach akademickich). Dlatego
wszystko jest oparte o system sesji a nie "live data". Patrząc na sprawę z
dzisiejszej perspektywy pewnie, że można było zrobić wiele rzeczy inaczej,
ale wiele spraw "wychodzi w praniu" a tu trzeba było zrobić system, który
zintegruje wszystkie większe polskie banki (które w pierwszej połowie lat
90-tych różnie wyglądały pod względem zinformatyzowania) i zrobi to "raz a
dobrze" (w kontekście tamtych czasów, gdzie nie było bankowości
internetowej).
A czemu system SORBNET ma kosztować? Bo jest znacznie kosztowniejszy w
utrzymaniu i ma znacznie większe wymagania od systemów które są w
poszczególnych bankach. To jak różnica między SMS-em a połączeniem
telefonicznym, w systemie Elixir banki robią zestawienie "off-line", potem
wysyłają "e-maila" do systemu centralnego, system centralny może sobie
kolejkować zadania, gdy już policzy salda i listy przelewów, to może to
odesłać ponownie do banku (w praktyce to bank sam odpytuje po kilku
godzinach) i bank przetwarza to też "w swoim tempie". Systemy bankowe mogą
działać na zasadzie "eksport do pliku/import z pliku", natomiast w
systemach RTGS po pierwsze system centralny musi być w stanie obsłużyć
szczytowe obciążenia na bieżąco (Elixir może sobie to kolejkować i
rozładować w czasie), a po drugie system bankowy musi być przystosowany do
księgowania "live" nawet podczas prac konserwacyjnych itp. (w systemie
Elixir można po prostu pobrać sesję w innym czasie).
Te wszystkie PayPale, Przelewy24 itp. przede wszystkim dają uniwersalne API
dla twórców sklepów internetowych bez potrzeby bezpośredniej obsługi na
przykład kart kredytowych, po prostu kupujesz usługę płatności i
przestajesz się interesować tym, że każdy klient ma konto w innym banku czy
używa innej karty płatniczej.
>>> Hardwareowa zbliżała się do granicy rozpadu krzemu na kwarki i
>>> wypadnięcia koralików z pamięci. Części zamienne w kilku muzeach były
>>> ale diabli wiedzą czy sprawne. 20 lat temu sam przyczyniłem sie do
>>> rozebrania, poprzez rozlutowanie na warsztatach szkolnych, jednej
>>> sztuki. Nie wiem czy bym chciał aby pracowała do dzisiaj - jakość
>>> montażu była tragiczna.
>>
>> Mimo wszystko pracowały kilkadziesiąt lat, obecny czas życia serwera to
>> kilka lat.
>
> Czemu nie jeździsz Fiatem 125p? Widuje je jeszcze na ulicach. Czemu nie
> używasz komórki wielkości bloczka? Czemu nie mieszkasz w lepiance?
> Argument, że komputer, synonim postępu i pędu technologicznego (sic!)
> pracował kilkadziesiąt lat jest ...antyargumentem.
Akurat co do samochodu, to nie trafiłeś, jeżdżę 20-letnim Mercedesem -
NIGDY nie stanął w drodze, zawsze bez problemu odpala zimą, a że nie ma
kupy plastiku i skai tylko skórę i metal - no cóż, dla mnie to nie wada,
jest duży i wygodny, a jak mi się kiedyś jakaś babka nową Yariską władowała
z tyłu, to ją odwieźli na lawecie a ja po prostu mogłem pojechać dalej,
tylko lakier był do poprawienia. Po co mam zmieniać ten samochód? Tylko
dlatego, że są nowsze modele? Co w ten sposób zyskam? O 1 litr mniejsze
zużycie paliwa na 100km? Gdybym kupił auto za 100_000PLN, to mi się ten
zakup "zwróci" w paliwie dopiero po przejechaniu pół miliona kilometrów, a
przy okazji nowe auta mają bardzo drogi serwis (jak z "tanimi" drukarkami,
kupujesz tanio, ale tonery/głowice drogie). Nie widzę ani jednego powodu
dla którego miałbym wymienić stare i sprawdzone auto na nowe.
Co do "antyargumentu" - jest na przykład taka firma Urban, która produkuje
maszyny przemysłowe (na przykład do stolarki budowlanej typu produkcja
drewnianych okien). Jaki jest sens wymiany komputerów sterujących tymi
maszynami co 2-3 lata? Maszyna pracuje powiedzmy 15-20 lat, to i komputer
sterujący też ma mieć żywotność 20 lat.
To że jakiś komputer pracował 20 lat nie jest antyargumentem, po prostu
pracował i już, to nic złego, że jakiś komputer steruje windami w jakimś
wieżowcu 20 lat i nikt go nie wymienia co rok na najnowszy model, to po
prostu racjonalne postępowanie.
>>> Bo jak pewnego dnia zejdzie operator na zawał to pociągi staną. Nie ma
>>> nikogo w zastępstwie. Koniec.
>>
>> I co to ma wspólnego z Odrą? Jeśli analogiczny system postawisz na chmurze
>> Amazona i wyszkolisz w jego obsłudze jednego operatora, to jak zejdzie, to
>> też "pociągi staną".
>
> Nie, wtedy znajdziesz 10 innych, bo chmura amazona to nowoczesna i
> popularna "technologia".
Miałem na myśli cały system a nie tylko os i hardware. Przykładowo napiszę
system do zarządzania pociągami, postawię to na wszem i wobez znanym
hardware, systemie operacyjnym itd. i zejdę na zawał, co z tego że znasz
się na hardware i os-ie, skoro moja aplikacja się wysypie i tylko ja wiem
jak to poskładać?
>>> Do pralek laduje się ARMy chodzące po kilkaset MHz. Nie dlatego że
>>> trzeba, tylko dlatego że ładowanie tam 8051 mija się z celem - ostatni
>>> programiści na ten badziew właśnie piszą testament.
>>
>> Te z którymi ja miałem do czynienia (Amica, Samsung, Siemens) nie miały
>> ARM-ów po kilkaset MHz tylko 8-bitowe kontrolery po kilkanaście MHz
>> (najczęściej FreeScale). Oczywiście są modele z "bajerami" typu wbudowany
>> tablet, ale mówię o typowych modelach.
>> 8051 to oczywiście zabytek i projektowanie NOWEGO systemu na czymś takim
>> jest bez sensu ale wiele już działających systemów będzie jeszcze działać
>> przez lata. Co do "ostatni programiści na ten badziew piszą właśnie
>> testament" - C to C, piny I/O to piny I/O, nie ma w tym jakiejś wielkiej
>> filozofii, jeśli ktoś jest obyty z mikrokontrolerami, to sobie poradzi bez
>> problemu. Nie trzeba do byle czego bawić się w stawianie kernela Linuxa na
>> ARM-ie, wbrew pozorom to nie upraszcza prostych projektów (typu pralka)
>> tylko je komplikuje.
>
> I jak myślisz, taniej jest zatrudnić developera C od układów 8 bit czy C na
> normalnym (nie okrojonym zasobowo) procesorze i z dostępem do bogatych
> bibliotek?
Na pewno do tego "zasobnego" wyjdzie drożej, bo do tego Linuxa trzeba
napisać drivery do kernela na konkretnego ARM-a, zbudować na tego ARM-a
minidystrybucję (aby ten "developer" mógł korzystać z "bogatych
bibliotek"), trzeba napisać system tak, aby radził sobie z natychmiastowym
brakiem zasilania ("bogate" systemy z mnóstwem bibliotek nie przepadają za
tym) itd. a to tylko proste firmware pralki. Stworzenie firmware na
8-bitowy prosty mikrokontroler (bez systemu operacyjnego) będzie znacznie
prostsze i tańsze (nawet totalni amatorzy, w tym dzieciaki z gimnazjum,
sobie z tym radzą pisząc soft na Arduino z 8-bitowymi AVR-ami, natomiast
ręka do góry kto napisał swój driver do Linuxa obsługujący nietypowy sprzęt
:D).
[toc] | [prev] | [next] | [standalone]
| From | szemrany <szemrany@offline.off> |
|---|---|
| Date | 2015-07-30 20:40 +0200 |
| Message-ID | <kisou3qdrhta$.9td8420kmx7e$.dlg@40tude.net> |
| In reply to | #27137 |
On Wed, 29 Jul 2015 23:32:13 +0000 (UTC), Pit wrote: >>>, było to w okolicach 2011 roku. W 2013 roku stary SORBNET został >>> zastąpiony systemem SORBNET2, który "rozładował" ruch. Dla Twojej >>> wiadomości, to obecnie większość przelewów Elixir jest "tunelowanych" >>> wewnątrz SORBNET2 (tylko Elixiry nie lecą "live" w momencie gdy je >>> wyklikasz na stronie banku, ale są wysyłane w paczkach 2-3 razy dziennie, >>> bo tak jest dla banku ZNACZNIE taniej). >> >> W sensie że banki płacą za kurierów z dyskietkami że wysłanie 100MB >> jednorazowo jest tańsze niż w kilkuset paczkach? A, to rozumiem. Że te >> dyskietki. Bo inaczej nie mogę pojąc jak wysyłanie 100MB w dowolnej >> konfiguracji może być w ogóle kosztowne. > > No ręce opadają :D Jeszcze powiedz, że na przykład operatorzy komórkowi > powinni oferować połączenia za darmo, bo przecież przesyłanie bajtów nic > nie kosztuje :D No i będą oferować za darmo, tak jak już oferują rozmowy telefoniczne, gdy kiedyś chcieli 2 czy 3 zł za każdą rozpoczętą minutę. Jeszcze chwila. > "Synchronizacja" systemów bankowych "live" jest kosztowniejsza niż robienie > tego sesjami co kilka godzin. To że SORBNET2 umożliwia rozliczanie zarówno > live jak i sesjami to po prostu kwestia konstrukcji tego systemu, co nie > oznacza, że obydwa te warianty są tak samo kosztowne (a że obecnie wiele > banków rozlicza "Elixiry" poprzez sesje SORBNET2 a nie poprzez dawny system > Elixir, to oczywista i zrozumiała sprawa, łatwiej jest utrzymać jeden > pozwalający na dwa warianty rozliczeń, niż dwa niezależne systemy). Ale CO JEST KOSZTOWNIEJSZE? Naprawdę masz na myśli łącze sieciowe? Bo za grzyba nie mogę wyobrazić sobie co może być droższego w połączeniu stałym od połączenia 3 razy na dobę. ps. stałe połączenie pozwoliłoby na zmniejszenie ruchu i nie dopuszczałoby do chwilowego obciążenia sieci, które występuje gdy się "pompuje" wszystko naraz -- howgh szemrany "Trzeba z żywymi naprzód iść, po życie sięgać nowe, a nie w uwiędłych laurów liść z uporem stroić głowę"
[toc] | [prev] | [next] | [standalone]
| From | Pit <nospam@sdf.lonestar.org> |
|---|---|
| Date | 2015-07-30 20:16 +0000 |
| Message-ID | <slrnmrl1hh.24i.nospam@nc10.lan> |
| In reply to | #27184 |
Dnia 30.07.2015 szemrany <szemrany@offline.off> napisał/a: >> No ręce opadają :D Jeszcze powiedz, że na przykład operatorzy komórkowi >> powinni oferować połączenia za darmo, bo przecież przesyłanie bajtów nic >> nie kosztuje :D > > No i będą oferować za darmo, tak jak już oferują rozmowy telefoniczne, gdy > kiedyś chcieli 2 czy 3 zł za każdą rozpoczętą minutę. Jeszcze chwila. Gdzie oferują *za darmo*? Bo mi oferują tylko nielimitowane rozmowy przy stałej *opłacie* abonamentowej (a i tak regulamin wspomina o "normalnym użytkowaniu" :D). Te moje "bezpłatne" połączenia na komórki, stacjonarne, SMS-y, MMS-y, "darmowe" 2GB internetu w telefonie itp. kosztuje mnie 50PLN miesięcznie (a, bym zapomniał, wziąłem jeszcze dla mamy telefon "za 1PLN"). 3PLN to rozmowy kosztowały jak operatorzy budowali infrastrukturę (sieć BTS-ów, pod które trzeba były wykupić/wynająć grunt, doprowadzić zasilanie, kupić same BTS-y, wybudować "maszty" itd.), jak pokrywanie kraju się skończyło (i skończyło spłacanie kredytów), to i ceny spadły (wstawienie karty do UMTS czy LTE do już istniejącego urządzenia jest znacznie tańsze, poza tym co innego kilkaset tysięcy aktywnych kart SIM w połowie lat 90-tych a co innego 40 milionów teraz - sam koszt utrzymania BTS-ów rozkłada się na więcej użytkowników). W każdym razie jeśli wierzysz, że dzwonisz za darmo, bo operator nie kasuje Cię za każdą minutę z osobna, to nie mam więcej pytań ;) >> "Synchronizacja" systemów bankowych "live" jest kosztowniejsza niż robienie >> tego sesjami co kilka godzin. To że SORBNET2 umożliwia rozliczanie zarówno >> live jak i sesjami to po prostu kwestia konstrukcji tego systemu, co nie >> oznacza, że obydwa te warianty są tak samo kosztowne (a że obecnie wiele >> banków rozlicza "Elixiry" poprzez sesje SORBNET2 a nie poprzez dawny system >> Elixir, to oczywista i zrozumiała sprawa, łatwiej jest utrzymać jeden >> pozwalający na dwa warianty rozliczeń, niż dwa niezależne systemy). > > Ale CO JEST KOSZTOWNIEJSZE? Naprawdę masz na myśli łącze sieciowe? Bo za > grzyba nie mogę wyobrazić sobie co może być droższego w połączeniu stałym > od połączenia 3 razy na dobę. > > ps. stałe połączenie pozwoliłoby na zmniejszenie ruchu i nie dopuszczałoby > do chwilowego obciążenia sieci, które występuje gdy się "pompuje" wszystko > naraz > To jest grupa o programowaniu, więc zakładam, że coś tam programujesz i na przykład systemy do zarządzania kodem pokroju Subversion czy Git znasz. Wyobraź sobie następującą analogię: pliki źródłowe to konta userów, programiści to banki, a serwer z repozytorium to KRI (czy NBP czy jakiekolwiek inne "centrum rozliczeń"). Przyjmijmy, że chodzi o Git-a. Dla "elixira" działa to tak, że zmieniasz sobie zawartość plików (stany kont), potem robisz commit (robisz zestawienie wszystkich stanów zmienionych kont, taki "point in time"), potem robisz push (wysyłasz zmiany do "serwera rozliczającego"), następnie inni robią pull (aby zobaczyć Twoje zmiany) jak i ty robisz pull (aby zobaczyć zmiany wprowadzone przez innych). Proste i nie wymaga wysokiej wydajności, bo push/pull w danej chwili robi jedna, bądź maksymalnie kilka osób jednocześnie (przy powiedzmy 100 osobach w zespole). A teraz wyobraź sobie, że masz zapewnić, aby każda zmiana dokonana przez każdego ze 100 członków zespołu była automatycznie dystrybuowana do wszystkich pozostałych (żadne commity, push/pull itd. tylko klikasz "save" w edytorze i wszyscy mają automatycznie widzieć zmianę), po pierwsze wszyscy muszą być praktycznie cały czas podłączeni do repo, a po drugie robiąc to na zasadzie "wpiszę do crontaba aby co minutę robił się automatycznie commit oraz push i pull" będzie wymagać znacznie większej wydajności serwera z repo. A to i tak w zasadzie "banalny" problem, bo w przypadku Git-a każdy ma u siebie praktycznie to samo (pełną kopię repo za wyjątkiem ostatnich zmian) więc większość rzeczy Git może zrobić po stronie klienta a na serwer wysyła tylko gotowe, już "przeliczone" dane, natomiast w przypadku systemów bankowych tak nie jest, każdy bank ma tylko dane dotyczące swoich kont i nie może sam przeprowadzić pełnego rozliczenia. Różnica w zapotrzebowaniu na moc obliczeniową jest spora.
[toc] | [prev] | [next] | [standalone]
| From | szemrany <szemrany@offline.off> |
|---|---|
| Date | 2015-07-31 18:11 +0200 |
| Message-ID | <1c8x618ol63rl$.1krxxcxnqgtql.dlg@40tude.net> |
| In reply to | #27186 |
On Fri, 31 Jul 2015 13:13:01 +0000 (UTC), Pit wrote: >> Po pierwsze napisałem, że to wersja uproszczona. Po drugie weryfikacja może >> sobie trwać, to się nie musi odbywać w milisekundach i w real timie. Klient >> klika "Wykonaj" i robi swoje, a system w tle dopełnia reszty, może to >> zakolejkować i zrobić, gdy będzie miał zasoby. > > Przykład trafiony jak to Twoje porównanie z "kapustą". Nie, system nie może > sobie najpierw dać Ci kasy na konto, a potem sobie w wolnym czasie > zaksięgować. Eeee, że co? Co znaczy "dać Ci kasy na konto"? Wszak danie na konto to właśnie księgowanie, czyli kasa pojawi się na koncie po tym jak proces się zakończy. Nie ma tu dualności żadnej. > O ile sesja elixir to jest JEDEN dokumenht elektroniczny > zawierający dziesiątki tysięcy pozycji (weryfikacje podpisów itd. robi się > raz), o tyle RTGS to dziesiątki tysięcy jednopozycyjnych dokumentów > elektronicznych (z których każdy musi zostać po jednej stronie podpisany a > po drugiej zweryfikowany). Sam "insert into" to detal, jak się kasa pojawia > na koncie, to znaczy, że wszystkie formalności zostały już załatwione. Ale ja z tym nie polemizuję! Ja polemizuję z twierdzeniem, że jest to tak cholernie obliczeniowo złożone, że serwery nie dadzą rady robić tego online i trzeba to robić metodami sprzed 20 lat. > Te wszystkie BlueCashe korzystają z tego, że banki mają uprawnienia > notarialne i poświadczają swoim podpisem elektronicznym dokumenty robione > przez innych (nawet moje czy Twoje przelewy - nasze hasła czy PIN-y z > tokenów to żaden podpis, bank poświadcza zlecenie za nas). A to tylko jeden > aspekt - ważność dokumentu (podpowiem - nie, nie wystarczy zrobić tego po > SSL-u i podpisać połączenie, musi być podpisany każdy dokument, bo ten > dokument wraz z podpisem musi być przechowywany przez ileś tam lat i musi > być weryfikowalny "sam w sobie", na przykład jeśli się go zgra na > przysłowiową dyskietkę). No i fajnie, tylko gdzie tu jest jakiś grubszy problem? >>> Czy się nie da? Oczywiście że się da, w końcu Elixirem biega około 2 >>> miliardy transakcji rocznie, czyli nic nadzwyczajnego, niecałe 7 milionów >>> transakcji dziennie uwzględniając tylko dni robocze, gdyby chodziło o samo >>> "insert into" to byłby to detal. >> >> To nadal jest detal. Jeśli sama obsługa komunikacji i baz to detal, a już >> obsługa uwierzytelniania i autoryzacji to kosmiczny wyczyn to ...cytując >> Ciebie... nie mam więcej pytań ;-) > > Pisałem nie o uwierzytelnianiu i autoryzacji, tylko o podpisie > elektronicznym, autoryzacja i uwierzytelnianie to osobna sprawa. Skoro nie > masz więcej pytań, to dziękuję za uwagę ;) Nie ma za co. Tak to już bywa, że czasem ludzie przyjmują zastane rozwiązania jako święte i nie dopuszczają do świadomości, że może być lepiej, bronią skrzywionej idei i udowadniają jej zasadność. >> Wyobraź sobie, że nie w weekend, ale na etacie "trzaskam" serwery RESTowe i >> zapieprzają aż miło. Mają też autoryzację i uwierzytelnianie, choć bez >> podpisów cyfrowych, nie ma takiej potrzeby. No i nie w Pythonie, ani innym >> języku skryptowym, są kompilowane do kodu natywnego maszyny. > > Twoje serwery nie obsługują dokumentów elektronicznych (w rozumieniu > prawnym), a przynajmniej tak zgaduję po tym co pisałeś (komputery > wspomagają przetwarzanie danych, ale jak trzeba formalnie, to jest papier). > Owszem, da się wszystko zrobić, ale aby zapewnić szybkie przelewy, to nie > wystarczy zmodernizować to, co jest w NBP, ale też wszystkie banki w tym > jakieś banki spółdzielcze w koziej wólce, bo i tak będziesz narzekał > "kurwa, miało być w 5 minut a kasy na koncie nie ma", No i w czym znów problem? Jeśli NBP i KIR wprowadzą taki system równolegle ze starym, to przelewy do banków które się nie podłączą pod system online nie będą online i klienci szybciutko zagłosują portfelami przeciw bankom, które się nie dostosują. Tak działa wolny rynek. -- howgh szemrany "Trzeba z żywymi naprzód iść, po życie sięgać nowe, a nie w uwiędłych laurów liść z uporem stroić głowę"
[toc] | [prev] | [next] | [standalone]
| From | Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> |
|---|---|
| Date | 2015-08-03 08:39 +0200 |
| Message-ID | <55bf0c85$0$8389$65785112@news.neostrada.pl> |
| In reply to | #27207 |
W dniu 2015-07-31 18:11, szemrany pisze: > On Fri, 31 Jul 2015 13:13:01 +0000 (UTC), Pit wrote: > >>> Po pierwsze napisałem, że to wersja uproszczona. Po drugie weryfikacja może >>> sobie trwać, to się nie musi odbywać w milisekundach i w real timie. Klient >>> klika "Wykonaj" i robi swoje, a system w tle dopełnia reszty, może to >>> zakolejkować i zrobić, gdy będzie miał zasoby. >> >> Przykład trafiony jak to Twoje porównanie z "kapustą". Nie, system nie może >> sobie najpierw dać Ci kasy na konto, a potem sobie w wolnym czasie >> zaksięgować. > > Eeee, że co? Co znaczy "dać Ci kasy na konto"? Wszak danie na konto to > właśnie księgowanie, czyli kasa pojawi się na koncie po tym jak proces się > zakończy. Nie ma tu dualności żadnej. Czasami ze względów optymalizacyjnych robiono tak, że wykonywane było uproszczone księgowanie, pełne wykonywane było wieczorem, gdy odłączano bazę. Przy księgowaniu musisz wykonać wielu zapisów informacyjnych, tak by później móc generować różnego rodzaju zestawienia. Część to po prostu wygoda projektantów systemu, żeby można było łatwo wyłuskać niektóre dane, część to rzeczy związane z przepisami, jak choćby przygotowanie do generowania sprawozdań o większych przelewach czy większym ruchu na koncie. -- Kaczus http://kaczus.ppa.pl
[toc] | [prev] | [next] | [standalone]
| From | Roman W <bloody_rabbitREMOVETHIS@gazeta.pl> |
|---|---|
| Date | 2015-08-02 03:09 +0100 |
| Message-ID | <almarsoft.479269823059650921@news.plus.net> |
| In reply to | #27186 |
On Sat, 1 Aug 2015 13:38:37 +0000 (UTC), Pit <nospam@sdf.lonestar.org> wrote: > Jeśli sugerujesz, że smutni panowie mają wielki przycisk STOP i patrzą na > każdy przelew pod kątem przepuścić czy nie, to tak nie jest, zajmują się > tylko analizą tego co już zostało zaksięgowane (nie wprost, robią to ich > komputery, które wyszukują "podejrzane przypadki") i ewentualnie blokują > "wybrańcom" konto. Wiem o tym. RW
[toc] | [prev] | [next] | [standalone]
| From | Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> |
|---|---|
| Date | 2015-08-03 08:34 +0200 |
| Message-ID | <55bf0b7c$0$8389$65785112@news.neostrada.pl> |
| In reply to | #27186 |
W dniu 2015-07-31 15:13, Pit pisze: > Dnia 31.07.2015 szemrany<szemrany@offline.off> napisał/a: >>> Cytując Ciebie "w nietrafionym uproszczeniu... tak". Myślisz, że w takich >>> systemach najbardziej czasochłonne są inserty do bazy? Same cyfrowe podpisy >>> do tych requestów oraz ich weryfikowanie zajmuje znacznie więcej niż insert >>> do bazy, no ale pewnie i tak wiesz lepiej... >> >> Po pierwsze napisałem, że to wersja uproszczona. Po drugie weryfikacja może >> sobie trwać, to się nie musi odbywać w milisekundach i w real timie. Klient >> klika "Wykonaj" i robi swoje, a system w tle dopełnia reszty, może to >> zakolejkować i zrobić, gdy będzie miał zasoby. > > Przykład trafiony jak to Twoje porównanie z "kapustą". Nie, system nie może > sobie najpierw dać Ci kasy na konto, a potem sobie w wolnym czasie > zaksięgować. Nie wiem jak obecnie, ale parę lat temu wiele systemów tak robiło. Niewiele było systemów pozwalających na pełne księgowanie od razu (chodziło o obciążenie bazy). Zauważyć to można było w ten sposób, że np system kartowy w pewnych godzinach odrzucał płatności - baza wtedy wykonywała "pełne księgowania". > Twoje serwery nie obsługują dokumentów elektronicznych (w rozumieniu > prawnym), a przynajmniej tak zgaduję po tym co pisałeś (komputery > wspomagają przetwarzanie danych, ale jak trzeba formalnie, to jest papier). > Owszem, da się wszystko zrobić, ale aby zapewnić szybkie przelewy, to nie > wystarczy zmodernizować to, co jest w NBP, ale też wszystkie banki w tym > jakieś banki spółdzielcze w koziej wólce, Akurat część banków spółdzielczych często jest bardziej nowoczesna niż duże banki - czy wiedziałeś, że np karty chipowe w niektórych takich bankach były dostępne już na początku tego tysiąclecia? Kiedy weszły do tzw dużych banków? Ile lat później? Największym problemem tu sa banki typu DB, czy do niedawna Nordea, gdzie w weekend, czy po pewnej godzinie nie masz onlinowych przelewów pomiędzy własnymi subkontami nawet! -- Kaczus http://kaczus.ppa.pl
[toc] | [prev] | [next] | [standalone]
| From | Budzik <budzik61@poczta.o.n.e.t.pl.nie.spam.oj> |
|---|---|
| Date | 2015-08-04 07:00 +0000 |
| Message-ID | <XnsA4EC52E01624Cbudzik61pocztaonetpl@127.0.0.1> |
| In reply to | #27238 |
Użytkownik Tomasz Kaczanowski kaczus@dowyciecia_poczta.onet.pl ... > Największym problemem tu sa banki typu DB, czy do niedawna Nordea, gdzie > w weekend, czy po pewnej godzinie nie masz onlinowych przelewów pomiędzy > własnymi subkontami nawet! Ja ostatnio zauwazyłem za taka niedogodnosc jest w... BZWBK... Tragedia - nie mieści mi sie to w głowie...
[toc] | [prev] | [next] | [standalone]
| From | szemrany <szemrany@offline.off> |
|---|---|
| Date | 2015-08-04 17:09 +0200 |
| Message-ID | <tmhihyxlumxm$.1na7qv8s0h5xa.dlg@40tude.net> |
| In reply to | #27238 |
On Mon, 03 Aug 2015 08:34:39 +0200, Tomasz Kaczanowski wrote: > Największym problemem tu sa banki typu DB Co to są banki typu DB? Pytam, bo nie wiem. -- howgh szemrany "Trzeba z żywymi naprzód iść, po życie sięgać nowe, a nie w uwiędłych laurów liść z uporem stroić głowę"
[toc] | [prev] | [next] | [standalone]
| From | Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> |
|---|---|
| Date | 2015-08-05 07:39 +0200 |
| Message-ID | <55c1a196$0$27512$65785112@news.neostrada.pl> |
| In reply to | #27242 |
W dniu 2015-08-04 17:09, szemrany napisał: > On Mon, 03 Aug 2015 08:34:39 +0200, Tomasz Kaczanowski wrote: > >> Największym problemem tu sa banki typu DB > > Co to są banki typu DB? Pytam, bo nie wiem. > DB to przykład banku, który wyłącza wykonywanie operacji w pewnych godzinach, przez internet możesz co najwyżej zlecić wykonanie jakiegoś przelewu, ale nawet między własnymi kontami operacja wykonana zostanie rano. -- Kaczus http://kaczus.republika.pl
[toc] | [prev] | [next] | [standalone]
| From | RW <bloody_rabbit@gazeta.pl> |
|---|---|
| Date | 2015-08-05 07:42 +0100 |
| Message-ID | <R4-dnZULHbzVLVzInZ2dnUU78RGdnZ2d@brightview.co.uk> |
| In reply to | #27243 |
Tomasz Kaczanowski wrote: > W dniu 2015-08-04 17:09, szemrany napisał: >> On Mon, 03 Aug 2015 08:34:39 +0200, Tomasz Kaczanowski wrote: >> >>> Największym problemem tu sa banki typu DB >> >> Co to są banki typu DB? Pytam, bo nie wiem. >> > DB to przykład banku, który wyłącza wykonywanie operacji w pewnych > godzinach, przez internet możesz co najwyżej zlecić wykonanie jakiegoś > przelewu, ale nawet między własnymi kontami operacja wykonana zostanie > rano. > DB to hedge fund ktory na boku bawi sie w bankowosc detaliczna. RW
[toc] | [prev] | [next] | [standalone]
Page 1 of 11 [1] 2 3 … 11 Next page →
Back to top | Article view | pl.comp.programming
csiph-web