Re: [dev] Just discovered dwm
again, libinput On 9/22/16, Greg Reagle wrote: > On Wed, Sep 21, 2016, at 12:10 PM, Nick Warne wrote: >> One little thing I do miss though is scrolling with mouse wheel (or >> using the pad side edge) to scroll a web page etc. >> Is that doable? > > If I had a mouse wheel I'd let you know how I do it, but I don't. I use > a track ball. I wonder if the xinput command would do the trick. This > is the command that I use to enable middle button emulation on my track > ball. > > xinput set-prop "Kensington Kensington USB/PS2 Orbit" "Evdev Middle > Button Emulation" 1 > > Maybe there is a wheel option. > >
Re: [dev] several questions
On 21 September 2016 at 16:45, Evan Gates wrote: > On Tue, Sep 20, 2016 at 11:02 PM, FRIGN wrote: >> Of course, given there is only one implementation, it is highly >> portable per-se, given the interpretation is equal everywhere and 9base >> is quite easily portable. > > Sadly there are two implementations. This rc[0] claims to be a > reimplementation for unix systems, but contains incompatible changes. > Here is the list of problems from the man page: There are two, but only the original one can be considered. Byron's rc was supposed to work in a regular unix environment with GNU userland. But especially its environment handling is completely different to the original rc, which allows exporting fn's. -Anselm
Re: [dev] Just discovered dwm
hiro wrote: networkmanager should be removed first thing on any distribution slack doesn't sound so great if it includes some crap tbh. It has PulseAudio in the default installation. And KDE is autoselected in the installer. Cág
Re: [dev] Just discovered dwm
On Sep 22 2016, Cág wrote: hiro wrote: networkmanager should be removed first thing on any distribution slack doesn't sound so great if it includes some crap tbh. It has PulseAudio in the default installation. And KDE is autoselected in the installer. Cág I have none of that installed - just base Slackware. Nick -- "Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"
Re: [dev] dwm systray diff for 6.1 fails.
On Sep 22 2016, Eric Pruitt wrote: On Wed, Sep 21, 2016 at 05:48:51PM +0100, Nick Warne wrote: Was going to use this to monitor battery, but HUNK #10 fails - looking at the patch and dwm.c, the code is totally different at around line 664: Are you using the tagged 6.1 release or 6.1/HEAD? My version of the patch applies cleanly against the current dwm HEAD: https://github.com/ericpruitt/edge/blob/master/patches/dwm-00-systray.diff I have stable release: http://dl.suckless.org/dwm/dwm-6.1.tar.gz and the diff that fails on HUNK#10 is: http://dwm.suckless.org/patches/dwm-6.1-systray.diff Nick -- "Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"
Re: [dev] several questions
On Wed, Sep 21, 2016 at 11:45:00AM -0400, stephen Turner wrote: > > On Tue, Sep 20, 2016 at 04:32:18PM -0400, stephen Turner wrote: > >> currently understand it bash at the least is expected to compile the linux > >> kernel. Is there any suitable projects that you may have seen around the Last time I compiled a linux kernel (a year ago), I did it with dash. The script which links the linux kernel was full of bash-isms. I fixed this, a year and a half ago, with the guy in charge of kbuild in the linux fondation, a.k.a. Michal Marek (once he was kind of forced to apply my patches by Ingo Molnar and Greg K.H. ...). I will soon compile a recent linux kernel (with that c++ garbage which is gcc unfortunately) for x86_64/x86 and see if that kbluid was damaged again. -- Sylvain
[dev] Suckless e-comerce script proposal
Hey all, I would like some feedback on some ideas I have for a script to make a very simple, but very secure, e-commerce website. Maybe it can be "slecommerce". The principal is: most of the website is static. Static index pages. Static item description pages. The item description pages link to a CGI script* with an ID for the product in a query string. So for example /cgi-bin/order?item=burgundy_shoes_23 The cgi script has a very simple text database containing: id name price stock count Script takes the user throught three steps: 1. filling out their details (simple question asked to check for human) 2. confirming that their details are correct 3. telling them that their order has been placed and giving them payment details to pay by bank transfer At stage three the user's data is saved on the server and the stock count info is updated. Becuase payment is by bank transfer user's data does not contain any financial information, just address, name and email etc. However for privacy perhaps user's data can be encrypted with asymmetric encryption before writing to disk? Script always checks stock immediately when called. If no stock, tells user and doesn't let the give any info. Advantages of this design: -One CGI script, everything else static. -Entire site requires no cookies or javascript. -Secure because user does not have to give any financial info, and shop's bank details are given over SSL. Limitations of this design: -Can only buy one item at a time, no shopping basket. For shopping basket we would need cookies. -Payment by bank transfer. -Stock control is updated before payment received, so on non-payment sysadmin must manually update stock-control. -If an item is out of stock, the user will not know until they try to buy it (because item description pages are static) Propose python3 for the script because it has excellect unicode handling, and good templating and RSA libraries available. I should mention I already made a shop that works like this[1]. Script is 407 LOC of python3, plus the jinja2 templating engine[2] and cryptography library[3] for assymetric encryption of user's data. Also sends emails. On this site the stock control is binary because there is only one of each item, so I was able to use UNIX file rename as an atomic stock control operation. Works fine even in eLinks. I haven't published the code of this implementation yet. Tell me what ya think, guys! *or self-serving HTTP script [1] https://www.freedcomputer.uk [2] http://jinja.pocoo.org/ [3] https://cryptography.io/en/latest/ -Joseph Graham P.S. I haven't really introduced myself here before. Hi everyone!
Re: [dev] Suckless e-comerce script proposal
On Thu, 22 Sep 2016, Joseph Graham wrote: > I would like some feedback on some ideas I have for a script to make a very > simple, but very secure, e-commerce website. Maybe it can be "slecommerce". I don't think highly domain-specific applications belong under the suckless umbrella. While each suckless tool does one thing, and does it well, the applications are always very broad. st is not a nethack-playing terminal, it's a terminal; dmenu is not just yet another command launcher, it's a generic menu system; etc. Of course it doesn't hurt to take some of the suckless principles (e.g. less code, clean code, simple architecture, few dependencies), and apply in your own projects. (just my $.02) <3,K.
Re: [dev] Suckless e-comerce script proposal
Hi Joseph, Joseph Graham wrote: > The principal is: most of the website is static. Static index pages. Static > item description pages. The item description pages link to a CGI script* with > an ID for the product in a query string. So for example > /cgi-bin/order?item=burgundy_shoes_23 First, it sucks to expose the fact that you are using a "common gateway interface" script to the user - Use a URL scheme like "/checkout?item=dope_shoes" or something. So what happens when you are out of stock on something? Do you re-generate the static pages? Or do you throw an error when the user tries to checkout? In the first case - you are re-generating (or re-caching) HTML in response to a user request, in the second, it is a sucky experience. > Becuase payment is by bank transfer user's data does not contain any financial > information, just address, name and email etc. However for privacy perhaps > user's data can be encrypted with asymmetric encryption before writing to > disk? Bank transfer? How is depending on the user to visit another website (which certainly uses JavaScript and all the things you are trying to avoid) decreasing the overall suck your users are experiencing? > -One CGI script, everything else static. Hopefully you are generating/compiling this static content from something, and not hand coding HTML on a ton of different pages. > -Can only buy one item at a time, no shopping basket. For shopping basket we > would need cookies. Buy one thing at a time, and re-enter my info a bunch of times in a row? Suck. > -Payment by bank transfer. Ever wonder why existing web sites don't do this? Because it wire transfers are terrible. Either you force users to use a bank website (Cookies + JavaScript, so you have just lost your moral high ground), or you force them to drive to a bank, or call up a bank. Such suck. If you are just thinking of suck as internal implementation complexity, you have the wrong mindset. You should be making APIs and user experiences that don't suck, even if that means you have some amount of (hidden to the user) internal implementation complexity. I don't care that YOUR life sucks less, I want you to help me make my life suck less. Besides, if you expect users to fill out an identical form for each item they want, and initiate a wire transfer on their own, you are going to go out of business. yours, Bobby
Re: [dev] Suckless e-comerce script proposal
* Bobby Powers [2016-09-22 09:28]: > Ever wonder why existing web sites don't do this? Because it wire > transfers are terrible. Either you force users to use a bank website > (Cookies + JavaScript, so you have just lost your moral high ground), > or you force them to drive to a bank, or call up a bank. Such suck. That's country specific. In Europe it's really common and with IBAN and BIC it's working international. Also have a look at FinTS (former HBCI) where you have public and private keys to communicate with your bank. And there is open source software to do all this. Cheers Jochen signature.asc Description: PGP signature
Re: [dev] Suckless e-comerce script proposal
Hi, Jochen Sprickerhof wrote: > That's country specific. In Europe it's really common and with IBAN and > BIC it's working international. Also have a look at FinTS (former HBCI) > where you have public and private keys to communicate with your bank. > And there is open source software to do all this. Are you saying that doing wire transfers in Europe is common, or doing wire transfers to pay for online goods? I'm glad to hear it is less of a horrendous experience, but it still feels like a suck idea to make customers jump through an additional hoop on their own, and expect them to correctly (and without error) copy/paste the correct amount from the order confirmation into a bank transfer form. If you suggest writing a script to automate this: it is suck to suggest customers write software to uniquely interact with your web site. yours, Bobby
Re: [dev] Suckless e-comerce script proposal
On Thu, 22 Sep 2016, Bobby Powers wrote: > Are you saying that doing wire transfers in Europe is common, or doing > wire transfers to pay for online goods? I'm glad to hear it is less > of a horrendous experience, but it still feels like a suck idea to > make customers jump through an additional hoop on their own, and > expect them to correctly (and without error) copy/paste the correct > amount from the order confirmation into a bank transfer form. If you > suggest writing a script to automate this: it is suck to suggest > customers write software to uniquely interact with your web site. In Poland, on most online shopping services, you click "pay with bank transfer" at the checkout. Click the logo of your bank, get a redirect to the bank's online transaction service, type in your user&pass, review the transaction, get an SMS with one-time code to confirm it, and click OK. It's marginally more complicated than typing the CC number and infinitely more secure (MFA, one-time codes are all standard). Transfers are instant, you usually get the goods the next day. However it's very JS-heavy, which is the only part that really sucks. <3,K.
Re: [dev] Suckless e-comerce script proposal
* Bobby Powers [2016-09-22 09:57]: > Are you saying that doing wire transfers in Europe is common, or doing > wire transfers to pay for online goods? It's common for both. > I'm glad to hear it is less > of a horrendous experience, but it still feels like a suck idea to > make customers jump through an additional hoop on their own, and > expect them to correctly (and without error) copy/paste the correct > amount from the order confirmation into a bank transfer form. If you > suggest writing a script to automate this: it is suck to suggest > customers write software to uniquely interact with your web site. I think it's a security feature and I wouldn't want to write software for that. As long as I initiate the transmission, I'm in control of my account. Otherwise I have to check every transmission for validity. * Kamil Cholewiński [2016-09-22 16:09]: > In Poland, on most online shopping services, you click "pay with bank > transfer" at the checkout. Click the logo of your bank, get a redirect > to the bank's online transaction service, type in your user&pass, review > the transaction, get an SMS with one-time code to confirm it, and click > OK. It's marginally more complicated than typing the CC number and > infinitely more secure (MFA, one-time codes are all standard). Transfers > are instant, you usually get the goods the next day. I would never do that. Having lot's of JS fiddling around in my bank account sounds scary. Also, any TAN system (be it SMS or whatever) is broken by design (and there are reports for people exploiting it for all of them). Cheers Jochen signature.asc Description: PGP signature
Re: [dev] Suckless e-comerce script proposal
On Thu, 22 Sep 2016, Jochen Sprickerhof wrote: > I would never do that. Having lot's of JS fiddling around in my bank > account sounds scary. You're more-or-less without a choice if you want to do online banking. Also safety in numbers. 99% of the cases of people getting pwned are because they open random links and don't look at their fucking address bar. > Also, any TAN system (be it SMS or whatever) is broken by design (and > there are reports for people exploiting it for all of them). Yes, because a three digit code printed on the back of your CC, that changes once in every 3-5 years, and that gets shared with three dozen different vendors, is s mch beeetteeer. When I want to shop for stuff needed at $WORK, basically I can no longer even look at Amazon, because we were getting CC frauds every few months. 10 years of dealing with my bank's crappy JS and SMS codes and I haven't been robbed off a single grosz. (Just my PLN 0.01) <3,K.
Re: [dev] Suckless e-comerce script proposal
On Thu, 22 Sep 2016 16:38:43 +0200 Kamil Cholewiński wrote: Hey Kamil, > You're more-or-less without a choice if you want to do online banking. > Also safety in numbers. 99% of the cases of people getting pwned are > because they open random links and don't look at their fucking address > bar. yes. > Yes, because a three digit code printed on the back of your CC, that > changes once in every 3-5 years, and that gets shared with three dozen > different vendors, is s mch beeetteeer. Exactly! > When I want to shop for stuff needed at $WORK, basically I can no > longer even look at Amazon, because we were getting CC frauds every > few months. 10 years of dealing with my bank's crappy JS and SMS > codes and I haven't been robbed off a single grosz. A good way to shop at Amazon is with gift cards. You can charge up your account to a certain baseline (e.g. 100 bucks) and then shop as you wish, with no trouble of cc frauds and all this crap. Amazon has no banking info on you but still it is really easy to manage. If you buy a bigger item, you just go to the store, get a few of the 100 buck gift cards, type the code in in no time (even faster than your cc card number) and it's all good. If you send an item back because you didn't like it, Amazon will automatically put the credit back on your gift card balance. Cheers FRIGN -- FRIGN
Re: [dev] Suckless e-comerce script proposal
On Thu, 22 Sep 2016 16:09:00 +0200 Kamil Cholewiński wrote: > In Poland, on most online shopping services, you click "pay with bank > transfer" at the checkout. Click the logo of your bank, get a redirect > to the bank's online transaction service, type in your user&pass, > review the transaction, get an SMS with one-time code to confirm it, > and click OK. It's marginally more complicated than typing the CC > number and infinitely more secure (MFA, one-time codes are all > standard). Transfers are instant, you usually get the goods the next > day. > > However it's very JS-heavy, which is the only part that really sucks. No, this is pure madness, it's not more secure than the other way around. Banks should provide their own APIs + SSO using a common/standard naming conventions and functionality. That doesn't sucks, the other way it does. It's enough a MitM attack or similar exploits to obtain user, password and other personal details and/or to forge payments that look like the original one. I know by experience. This doesn't mean that Poland e-commerce solutions aren't safe, it just means that you are using the "suck more" solution. BTW, having a "suck less" e-commerce it's good, but I'm also strongly convinced that it doesn't belong to suckless. My 2¢ -- -BEGIN GEEK CODE BLOCK- Version: 3.12 GIT !d s: !a C++ UL P+++ L+++ E--- W+++ N+++ o-- K- w--- O+ M-- V-- PS+++ PE Y+ PGP t+++ 5++ X R++ tv- b+ DI D++ G e+ h r+++ y --END GEEK CODE BLOCK--
Re: [dev] Suckless e-comerce script proposal
* Kamil Cholewiński [2016-09-22 16:38]: > Yes, because a three digit code printed on the back of your CC, that > changes once in every 3-5 years, and that gets shared with three dozen > different vendors, is s mch beeetteeer. Huh, I never proposed that, but rather FinT which has strong cryptography (think of gnupg) as it's background. Cheers Jochen signature.asc Description: PGP signature
Re: [dev] Suckless e-comerce script proposal
On Thu, 22 Sep 2016, FRIGN wrote: > A good way to shop at Amazon is with gift cards. [...] Thanks for the tip! I'll share this with our IT dept.
Re: [dev] Suckless e-comerce script proposal
On Thu, 22 Sep 2016 17:56:24 +0200 Kamil Cholewiński wrote: Hey Kamil, > Thanks for the tip! I'll share this with our IT dept. are you being sarcastic? Of course you can't use it for corporation-size investments, but for personal stuff, it really works out. As an added bonus, I think that when I see something on Amazon I would much rather buy something I don't need with a CC or PayPal than going to the store and buying the gift cards, as on the way to and from the store I have time to re-think the upcoming purchase. Just like they're trying to take the ready cash from us to force us into quick buying decisions with our credit cards, Apple Pay and other NFC technologies, PayPal and possibly implanted microchips in the future, buying things on the web are designed the same way. Of course you can't pay with cash online, but it makes sense to think about alternatives that come as close as possible, namely giftcards. Cheers FRIGN -- FRIGN
Re: [dev] Just discovered dwm
On 22 Sep 2016 09:51:00 +0100 Nick Warne wrote: > On Sep 22 2016, Cág wrote: > > >hiro wrote: > > > >> networkmanager should be removed first thing on any distribution > >> slack doesn't sound so great if it includes some crap tbh. > > > >It has PulseAudio in the default installation. And KDE is > >autoselected in the > >installer. > > > >Cág > > I have none of that installed - just base Slackware. Just got in from work and read the 14.2 release - pulseaudio? Bloody hell. I still run 14.1, and that only has alsa and also KDE stuff is only a singleton option on install - it can be deselected to not install any of it (which I do). I would say 14.2 follows the same logic. You don't have to install KDE and pulseaduio crap - just deselect them. Nick -- "Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"
[dev] ot: C Standard noreturn
Hi,
how does noreturn attribute work? Trying to get this [0] to work, I
error on noreturn.
/* Note how buffer overruns are undefined behavior and the compilers tend to
optimize these checks away if you wrote them yourself, this only works
robustly because the compiler did it itself. */
extern uintptr_t __stack_chk_guard;
noreturn void __stack_chk_fail(void);
void foo(const char* str)
{
uintptr_t canary = __stack_chk_guard;
char buffer[16];
strcpy(buffer, str);
if ( (canary = canary ^ __stack_chk_guard) != 0 )
__stack_chk_fail();
}
main.c:7:10: error: expected ???=???, ???,???, ???;???, ???asm??? or
???__attribute__??? before ???void???
noreturn void __stack_chk_fail(void);
tried
void __stack_chk_fail(void) __attribute ((noreturn));
instead.
[0] http://wiki.osdev.org/Stack_Smashing_Protector
Re: [dev] ot: C Standard noreturn
On Thu, Sep 22, 2016 at 11:04 AM, wrote:
>
> Hi,
>
> how does noreturn attribute work? Trying to get this [0] to work, I
> error on noreturn.
>
> /* Note how buffer overruns are undefined behavior and the compilers tend to
>optimize these checks away if you wrote them yourself, this only works
>robustly because the compiler did it itself. */
> extern uintptr_t __stack_chk_guard;
> noreturn void __stack_chk_fail(void);
> void foo(const char* str)
> {
> uintptr_t canary = __stack_chk_guard;
> char buffer[16];
> strcpy(buffer, str);
> if ( (canary = canary ^ __stack_chk_guard) != 0 )
> __stack_chk_fail();
> }
>
>
>
> main.c:7:10: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before
> ‘void’
> noreturn void __stack_chk_fail(void);
>
> tried
> void __stack_chk_fail(void) __attribute ((noreturn));
> instead.
>
>
> [0] http://wiki.osdev.org/Stack_Smashing_Protector
>
`noreturn` is usually used in exception code, kernel code, libc [0],
or other systems code. It signifies to the compiler, whether there is
a return type or void, that it is possible that the callee function
will not return to the caller function. Often you will see a `while(
true );` or `for(;;);` at the end of the function to make it more
obvious for the next developer. Adding a `noreturn` will keep the
compiler from complaining/ warning/ erroring when it encounters this
function.
For your case, you may need to add that infinite loop at the end of
the function.
[0]
https://git.musl-libc.org/cgit/musl/tree/src/exit/_Exit.c?id=e738b8cbe64b6dd3ed9f47b6d4cd7eb2c422b38d
Re: [dev] ot: C Standard noreturn
On Thu, Sep 22, 2016 at 08:04:44PM +0200, u...@netbeisser.de wrote: > main.c:7:10: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before > ‘void’ > noreturn void __stack_chk_fail(void); > noreturn is already a return type (in as much as void is one, namely syntactically), so remove the "void" and you should be fine. > tried > void __stack_chk_fail(void) __attribute ((noreturn)); > instead. > That however only works with gcc and compatibles. Ciao, Markus
[dev] slackware custom build
This is a bit off topic and i wanted to avoid thread jacking another conversation. I see people here are using slackware, i was considering a script package management system that allows for easy modifications for a "micro distribution" the idea was to not host any of the actual source but do everything through scripts. I see slackware does host the source tar balls but they have a script inside that facilitates the install?
Re: [dev] ot: C Standard noreturn
On Thu, Sep 22, 2016 at 09:03:57PM +0200, Markus Wichmann wrote:
> On Thu, Sep 22, 2016 at 08:04:44PM +0200, u...@netbeisser.de wrote:
> > main.c:7:10: error: expected ???=???, ???,???, ???;???, ???asm??? or
> > ???__attribute__??? before ???void???
> > noreturn void __stack_chk_fail(void);
> noreturn is already a return type (in as much as void is one, namely
> syntactically), so remove the "void" and you should be fine.
>
> > tried
> > void __stack_chk_fail(void) __attribute ((noreturn));
> > instead.
> That however only works with gcc and compatibles.
Thanks for pointing out. In the meantime I wrote this, because I had a look at
libssp.
I will call it money :)
#include
int main(int argc, char **argv) {
if (strstr(argv[1],"buf")) {
__chk_fail();
} else if (strstr(argv[1],"fmt")) {
__stack_chk_fail();
}
return 0;
}
Re: [dev] slackware custom build
On Thu, 22 Sep 2016 15:06:07 -0400 stephen Turner wrote: > This is a bit off topic and i wanted to avoid thread jacking another > conversation. > > I see people here are using slackware, i was considering a script > package management system that allows for easy modifications for a > "micro distribution" the idea was to not host any of the actual source > but do everything through scripts. I see slackware does host the > source tar balls but they have a script inside that facilitates the > install? > Try: https://slackbuilds.org/ I use it a lot. But I also have a directory called 'progs' in my $HOME that I install stuff in to keep the system clean ~ obviously you need to supply path info when using it, but e.g. dwm, st, dillo, claws-mail all live there. Nick -- "Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"
Re: [dev] Just discovered dwm
then it's no better than ubuntu. i can deselect stuff there, too.
Re: [dev] Suckless e-comerce script proposal
Thanks guys, I've recieved some good honest feedback, especially from Bobby. I like FRIGN's idea of using gift-cards to buy from amazon. Remonds me of how I used to use a pay-as-you-go phone which I only topped up with cash. -Joseph
Re: [dev] Just discovered dwm
I liked the old debian floppy net install, 75 mb base cli only image. apt get your way to happiness. It didn't fit with the suckless as they did a lot to their system but it wasn't ubuntu. These days you can't even install a Cli for less than 100+ mb. i really don't understand what they are feeding these programs. On Thu, Sep 22, 2016 at 3:31 PM, hiro <23h...@gmail.com> wrote: > then it's no better than ubuntu. i can deselect stuff there, too. >
Re: [dev] Just discovered dwm
On Thu, 22 Sep 2016 21:31:09 +0200 hiro <23h...@gmail.com> wrote: > then it's no better than ubuntu. i can deselect stuff there, too. > So you use ubuntu? - deselect systemd? What I meant was pulseaduio, KDE et al isn't a base requirement - just if you want it. Nick -- "Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"
Re: [dev] Suckless e-comerce script proposal
On Thu, Sep 22, 2016 at 09:28:56AM -0400, Bobby Powers wrote: > Hi Joseph, > > Joseph Graham wrote: > > The principal is: most of the website is static. Static index pages. Static > > item description pages. The item description pages link to a CGI script* > > with > > an ID for the product in a query string. So for example > > /cgi-bin/order?item=burgundy_shoes_23 > > First, it sucks to expose the fact that you are using a "common > gateway interface" script to the user - Use a URL scheme like > "/checkout?item=dope_shoes" or something. > Hiding the internals of the system just for the sake of hiding them sounds like Microsoft's philosophy. > > So what happens when you are out of stock on something? Do you > re-generate the static pages? Or do you throw an error when the user > tries to checkout? In the first case - you are re-generating (or > re-caching) HTML in response to a user request, in the second, it is a > sucky experience. Just throws an error. > > > Becuase payment is by bank transfer user's data does not contain any > > financial > > information, just address, name and email etc. However for privacy perhaps > > user's data can be encrypted with asymmetric encryption before writing to > > disk? > > Bank transfer? How is depending on the user to visit another website > (which certainly uses JavaScript and all the things you are trying to > avoid) decreasing the overall suck your users are experiencing? > Well, they can just phone up. > > -One CGI script, everything else static. > > Hopefully you are generating/compiling this static content from > something, and not hand coding HTML on a ton of different pages. > Yep, hand coding. > > -Can only buy one item at a time, no shopping basket. For shopping basket we > > would need cookies. > > Buy one thing at a time, and re-enter my info a bunch of times in a row? > Suck. > Well it depends what type of shop it is... if it's a computer shop it doesn't matter since people don't normally order 2 computers at once. > > -Payment by bank transfer. > > Ever wonder why existing web sites don't do this? Because it wire > transfers are terrible. Either you force users to use a bank website > (Cookies + JavaScript, so you have just lost your moral high ground), > or you force them to drive to a bank, or call up a bank. Such suck. > The thing with card payments is that you give your card details to dosens of different shopping websites, creating a large "attack surface" for those details to be stolen. With bank transfer there's only 1 point of failure instead of dosens. > > If you are just thinking of suck as internal implementation > complexity, you have the wrong mindset. You should be making APIs and > user experiences that don't suck, even if that means you have some > amount of (hidden to the user) internal implementation complexity. I > don't care that YOUR life sucks less, I want you to help me make my > life suck less. > > Besides, if you expect users to fill out an identical form for each > item they want, and initiate a wire transfer on their own, you are > going to go out of business. > > yours, > Bobby > Thanks for feedback I appreciate it. -Joseph
Re: [dev] Just discovered dwm
you're right that ubuntu systemd is too difficult to remove. there are solutions for the people who want a 100MB debian CLI install: you can use debian packages without debian, too (not gonna guide your direction with more details though).
Re: [dev] Suckless e-comerce script proposal
Hi Joseph! Joseph Graham wrote: > Hiding the internals of the system just for the sake of hiding them sounds > like > Microsoft's philosophy. Think of it the other way: what is gained by showing the user "/cgi-bin/"? I suggest it conveys 0 bits of useful information to the user, and clutters the URL. > Yep, hand coding. I suggest a static site generator, as it nicely decomposes the creation of content from the styling of the content. > Well it depends what type of shop it is... if it's a computer shop it doesn't > matter since people don't normally order 2 computers at once. Sure - but what if they want a computer and an external mouse? Or a laptop and a bag and an external power adapter? > The thing with card payments is that you give your card details to dosens of > different shopping websites, creating a large "attack surface" for those > details to be > stolen. With bank transfer there's only 1 point of failure instead of dosens. It sounds like wire transfers are more common in Europe. There are also payment processors like Stripe, Braintree, and Paypal who can handle the details of credit card processing for you, so that you don't have to deal with the hassles of securing and documenting your handling of credit card info. > Thanks for feedback I appreciate it. Of course, best of luck :) yours, Bobby
Re: [dev] Suckless e-comerce script proposal
Yes, make the site static & host on S3/CloudFront. Generate from a DB of your stock/inventory. Go lang's html/template makes this painless. Dynamic bits should be ReactJS chatting with Stripe APIs. I would go so far as use Stripe to store the customer object et al. You can get it back out easy enough if you need to make a move. Have fun,
