Re: [dev][all] Migrating build system
Why don't you have a peak at that date On 04/02/2017 09:56 AM, Pickfire wrote: > Aditya Goturu wrote: > >> As we know, the greatest weakness of suckless apps is their dependence on >> bloated build systems like make. >> >> I tried porting to to gnu autotools, but while it helped, it still needed >> work. >> >> I am proposing we migrate to visual studio as our build system immediately. >> We must also start reimplementing some parts in modern languages like C# or >> Java. >> >> I also propose we stop using this mailing list immediately and move to a >> better communication platform like Microsoft Exchange and that we replace >> IRC with slack. >> >> Thanks >> Aditya > What? Are you sure that you are in the right place?
Re: [dev][all] Migrating build system
On 04/01/2017 03:03 PM, David Phillips wrote: > On Sat, Apr 01, 2017 at 02:46:36PM +0530, Aditya Goturu wrote: >> I am proposing we migrate to visual studio as our build system immediately. >> We must also start reimplementing some parts in modern languages like C# or >> Java. > Have you seen FRIGN's efforts on porting sbase to Java [1] ? > Perhaps you could collaborate with him on this. I have been considering this, and realized that as Java is a very weak VM, and we are better off implementing C# on a VAX11/70 virtual machine. >> I also propose we stop using this mailing list immediately and move to a >> better communication platform like Microsoft Exchange and that we replace >> IRC with slack. > I prefer Yahoo! Groups. It's clean, tidy, and minimalist. > >> Thanks >> Aditya > Cheers! > David > > [1]: http://lists.suckless.org/dev/1404/20654.html
Re: [dev][all] Migrating build system
Yes, I have considered yahoo groups. It will also allow us to view similar intellectually challenging questions on the same page, such as 'how is babby formed'. On 04/01/2017 03:03 PM, David Phillips wrote: > On Sat, Apr 01, 2017 at 02:46:36PM +0530, Aditya Goturu wrote: >> I am proposing we migrate to visual studio as our build system immediately. >> We must also start reimplementing some parts in modern languages like C# or >> Java. > Have you seen FRIGN's efforts on porting sbase to Java [1] ? > Perhaps you could collaborate with him on this. > >> I also propose we stop using this mailing list immediately and move to a >> better communication platform like Microsoft Exchange and that we replace >> IRC with slack. > I prefer Yahoo! Groups. It's clean, tidy, and minimalist. > >> Thanks >> Aditya > Cheers! > David > > [1]: http://lists.suckless.org/dev/1404/20654.html
Re: [dev] [slock] [PATCH] Add option to show the password on the screen
Actually, I have a better suggestion. Rather than burdening the user with things like passwords, we must make it such that it will simply allow the user to unlock as soon as the enter key is pressed. Perhaps we should integrate with Microsoft Active Directory to allow this. On 04/01/2017 02:26 PM, s...@mailless.org wrote: > * David Phillips 2017-04-01 06:42 >> With slock's current behaviour, the user can become frustrated when they >> suspect that they have made a typo in their password and are unable to >> remember how many times to hit the backspace key to correct it. > what's wrong with hitting enter to start over (you submit the pasword; > if it's wrong, you start over)? > > cheers > --s
[dev][all] Migrating build system
As we know, the greatest weakness of suckless apps is their dependence on bloated build systems like make. I tried porting to to gnu autotools, but while it helped, it still needed work. I am proposing we migrate to visual studio as our build system immediately. We must also start reimplementing some parts in modern languages like C# or Java. I also propose we stop using this mailing list immediately and move to a better communication platform like Microsoft Exchange and that we replace IRC with slack. Thanks Aditya
Re: [dev] [announce] ff2sixel: view farbfeld images in terminal
Ah that patch does what I need. Thanks! On 03/20/2017 10:22 PM, Cág wrote: > Aditya Goturu wrote: > >> I personally like it because it won't disturb any window >> layout I had open already. > One could've used the swallow patch[0]. > > There's already Terminology[1], the Eclipse of terminal > emulators. > > [0]: http://dwm.suckless.org/patches/swallow > [1]: https://www.enlightenment.org/about-terminology > > -- > Cág
Re: [dev] [announce] ff2sixel: view farbfeld images in terminal
After I thoroughly reconsidered by window manager configuration, yep I agree On 03/20/2017 07:30 PM, robin wrote: > On Mon, Mar 20, 2017 at 11:16:58AM +0100, hiro wrote: >> there's nothing convenient in your pityful setup. >> >> "won't disturb any window layout I had open already" >> fix your window manager, seems it's not able to manage shit. >> >> that escape you're talking about is called execve and it works just fine. > Man, I love the spirit of suckless (subset of suckless). > If only the same honesty could be applied throughout life without bad outcome.
Re: [dev] [announce] ff2sixel: view farbfeld images in terminal
One could argue its a little more convenient. I personally like it because it won't disturb any window layout I had open already. Here's a thought: Rather than adding all the code to the terminal, a simple patch could be made which detects a certain escape and will pipe everything after that for X bytes into some image viewer. That could be another separate program. And we don't need to use sixel, we just push the raw farbfeld. On 03/20/2017 02:40 PM, hiro wrote: > why would one want to view images in st, can't your shell start other > graphical programs for that? is st becoming a new kind of web browser > now? and why don't you open remote images using a remote file system > instead of fucking around with remote shells and then trying to > display them in a local terminal?! > > i mean even loonix can do this already. sshfs, qiv (or other proper > graphical application of your choice). you even have a window manager > in your same old project here, why not open some windows already? > > On 3/20/17, Laslo Hunhold wrote: >> On Mon, 20 Mar 2017 02:57:20 +0300 >> Alexander Krotov wrote: >> >> Hey Alexander, >> >>> I have crafted a program to convert farbfeld images to sixels: >>> https://github.com/ilabdsf/ff2sixel >> this is very cool! Sixels are definitely an interesting concept to view >> images over an SSH-connection. >> >>> Too bad st does not have a patch to display sixels, so I am going >>> to use mlterm when I need to browse images. One simple way to >>> implement it in st is to cut out sixel images, convert them back >>> to farbfeld (with separate process) and pass result to lel. Not >>> going to do it now, just an idea. >> There were discussions on sixel support in st, and I think even some >> code written for it. Can anybody give a status update on that one? >> >> With best regards >> >> Laslo >> >> -- >> Laslo Hunhold >> >>
Re: [dev] Linux distros that don't suck too too much
I actually asked juan rp about that plist thing, he said it was because he had experience with it on netbsd with proplib, which he then ported as portable proplib: https://github.com/xtraeme/portableproplib. On Wed, May 11, 2016 at 4:41 PM, Teodoro Santoni wrote: > Hi, > > 2016-05-11 12:56 GMT+02:00, Nick : >> Hi folks, >> >> A few nights ago my too-expensive laptop met with too-cheap wine and now >> it is a far-too-expensive brick. As it's therefore time for me to >> install a new OS on a new laptop, I was wondering what people would >> recommend. I've been using Debian Stable for years now, which while it >> sucks does work well enough that I don't have to think about it very >> much, so I can do more interesting things with my time. But particularly >> after reading a few good articles about issues with debian [0] [1] I >> find myself wondering if there's a better option out there. A rolling >> release distribution would be fine with me, but only if it didn't break >> often at all; I enjoyed using Gentoo years ago when I was a student, but >> keeping it working took a lot of time that I do not want to dedicate to >> keeping a working system these days. I'd like to try something like >> morpheus [2], but I suspect that would take quite a lot of time and >> energy to get going and maintain. > > I've used Void Linux for some times now. > The only thing that breaks sometimes it's the package manager > and its build tree. But 99% of the time it turns up without any intervention. > More on it: it doesn't seem so shitty when you use it (I find it > better than apt), > but uses xml files (.plist) as package database. > If you'll give up with Gentoo, i recommend it. > -- Aditya Goturu "The most dangerous phrase in the language is, We’ve always done it this way" - Grace Hopper Pubkey 4096R/727CEEED on pgp.mit.edu.
Re: [dev] "Note On Webkit Versions"
WOW. The compile took 7 mins but there was only 1 (ONE) warning and NO errors after i installed libXmu-devel on my server. The bad news: it doesnt run on an X11 tunnel On Mon, May 2, 2016 at 10:56 AM, Aditya Goturu wrote: > Argh. Compile failed. But i found out some more interesting things. > The BUILD SYSTEM depends on python and DBUS. Also, when the compile > finished, it popped up a GUI notification (!), on the machine on which > i ssh -Yed into the build server... > > On Mon, May 2, 2016 at 10:53 AM, Aditya Goturu wrote: >> Cargo pulling in libs for servo on a system with just rustc installed: >> Updating registry `https://github.com/rust-lang/crates.io-index` >> Updating git repository `https://github.com/servo/rust-layers` >> Updating git repository `https://github.com/servo/webrender` >> Updating git repository `https://github.com/servo/ipc-channel` >> Updating git repository `https://github.com/servo/webrender_traits` >> Updating git repository `https://github.com/browserhtml/browserhtml` >> Updating git repository `https://github.com/servo/gaol` >> Updating git repository `https://github.com/emilio/angle` >> Updating git repository `https://github.com/servo/rust-mozjs` >> Updating git repository `https://github.com/servo/rust-azure` >> Updating git repository `https://github.com/servo/rust-freetype` >> Updating git repository `https://github.com/aweinstock314/rust-clipboard` >> Updating git repository `https://github.com/energymon/energymon-rust.git` >> Updating git repository `https://github.com/energymon/energymon-sys.git` >> Updating git repository `https://github.com/ende76/brotli-rs` >> Updating git repository `https://github.com/jdm/tinyfiledialogs` >> Updating git repository `https://github.com/servo/mozjs` >> Updating git repository `https://github.com/huonw/simd` >> Downloading url v1.0.0 >> Downloading libc v0.2.10 >> Downloading euclid v0.6.6 >> Downloading gleam v0.2.15 >> Downloading env_logger v0.3.3 >> Downloading app_units v0.2.3 >> Downloading heapsize v0.3.5 >> Downloading num v0.1.32 >> Downloading serde v0.7.0 >> Downloading rand v0.3.14 >> Downloading serde_macros v0.7.2 >> Downloading lazy_static v0.1.16 >> Downloading getopts v0.2.14 >> Downloading backtrace v0.2.1 >> Downloading smallvec v0.1.5 >> Downloading log v0.3.6 >> Downloading deque v0.3.1 >> Downloading bitflags v0.6.0 >> Downloading rustc-serialize v0.3.19 >> Downloading string_cache v0.2.13 >> Downloading num_cpus v0.2.10 >> Downloading heapsize_plugin v0.1.4 >> Downloading kernel32-sys v0.2.1 >> Downloading winapi v0.2.6 >> Downloading winapi-build v0.1.1 >> Downloading serde_codegen v0.7.2 >> Downloading quasi v0.9.0 >> Downloading aster v0.15.0 >> Downloading quasi_macros v0.9.0 >> Downloading quasi_codegen v0.9.0 >> Downloading num-traits v0.1.32 >> Downloading num-integer v0.1.32 >> Downloading num-bigint v0.1.32 >> Downloading num-complex v0.1.32 >> Downloading num-rational v0.1.32 >> Downloading num-iter v0.1.32 >> Downloading matches v0.1.2 >> Downloading encoding v0.2.32 >> Downloading idna v0.1.0 >> Downloading encoding-index-japanese v1.20141219.5 >> Downloading encoding-index-tradchinese v1.20141219.5 >> Downloading encoding-index-singlebyte v1.20141219.5 >> Downloading encoding-index-korean v1.20141219.5 >> Downloading encoding-index-simpchinese v1.20141219.5 >> Downloading encoding_index_tests v0.1.4 >> Downloading unicode-normalization v0.1.2 >> Downloading unicode-bidi v0.2.3 >> Downloading cfg-if v0.1.0 >> Downloading backtrace-sys v0.1.3 >> Downloading dbghelp-sys v0.2.0 >> Downloading phf_shared v0.7.13 >> Downloading debug_unreachable v0.0.6 >> Downloading unreachable v0.0.2 >> Downloading void v0.0.5 >> Downloading phf_generator v0.7.13 >> Downloading tenacious v0.2.0 >> Downloading bincode v0.5.6 >> Downloading byteorder v0.5.1 >> Downloading uuid v0.2.0 >> Downloading libz-sys v1.0.0 >> Downloading gcc v0.3.26 >> Downloading pkg-config v0.3.8 >> Downloading offscreen_gl_context v0.1.3 >> Downloading gl_generator v0.5.1 >> Downloading xml-rs v0.3.0 >> Downloading khronos_api v1.0.0 >> Downloading bitflags v0.3.3 >> Downloading x11 v2.3.0 >> Downloading image v0.9.0 >> Downloading time v0.1.34 >> Downloading cssparser v0.5.5 >> Downloading hyper v0.9.1 >> Downloading servo
Re: [dev] "Note On Webkit Versions"
Argh. Compile failed. But i found out some more interesting things. The BUILD SYSTEM depends on python and DBUS. Also, when the compile finished, it popped up a GUI notification (!), on the machine on which i ssh -Yed into the build server... On Mon, May 2, 2016 at 10:53 AM, Aditya Goturu wrote: > Cargo pulling in libs for servo on a system with just rustc installed: > Updating registry `https://github.com/rust-lang/crates.io-index` > Updating git repository `https://github.com/servo/rust-layers` > Updating git repository `https://github.com/servo/webrender` > Updating git repository `https://github.com/servo/ipc-channel` > Updating git repository `https://github.com/servo/webrender_traits` > Updating git repository `https://github.com/browserhtml/browserhtml` > Updating git repository `https://github.com/servo/gaol` > Updating git repository `https://github.com/emilio/angle` > Updating git repository `https://github.com/servo/rust-mozjs` > Updating git repository `https://github.com/servo/rust-azure` > Updating git repository `https://github.com/servo/rust-freetype` > Updating git repository `https://github.com/aweinstock314/rust-clipboard` > Updating git repository `https://github.com/energymon/energymon-rust.git` > Updating git repository `https://github.com/energymon/energymon-sys.git` > Updating git repository `https://github.com/ende76/brotli-rs` > Updating git repository `https://github.com/jdm/tinyfiledialogs` > Updating git repository `https://github.com/servo/mozjs` > Updating git repository `https://github.com/huonw/simd` > Downloading url v1.0.0 > Downloading libc v0.2.10 > Downloading euclid v0.6.6 > Downloading gleam v0.2.15 > Downloading env_logger v0.3.3 > Downloading app_units v0.2.3 > Downloading heapsize v0.3.5 > Downloading num v0.1.32 > Downloading serde v0.7.0 > Downloading rand v0.3.14 > Downloading serde_macros v0.7.2 > Downloading lazy_static v0.1.16 > Downloading getopts v0.2.14 > Downloading backtrace v0.2.1 > Downloading smallvec v0.1.5 > Downloading log v0.3.6 > Downloading deque v0.3.1 > Downloading bitflags v0.6.0 > Downloading rustc-serialize v0.3.19 > Downloading string_cache v0.2.13 > Downloading num_cpus v0.2.10 > Downloading heapsize_plugin v0.1.4 > Downloading kernel32-sys v0.2.1 > Downloading winapi v0.2.6 > Downloading winapi-build v0.1.1 > Downloading serde_codegen v0.7.2 > Downloading quasi v0.9.0 > Downloading aster v0.15.0 > Downloading quasi_macros v0.9.0 > Downloading quasi_codegen v0.9.0 > Downloading num-traits v0.1.32 > Downloading num-integer v0.1.32 > Downloading num-bigint v0.1.32 > Downloading num-complex v0.1.32 > Downloading num-rational v0.1.32 > Downloading num-iter v0.1.32 > Downloading matches v0.1.2 > Downloading encoding v0.2.32 > Downloading idna v0.1.0 > Downloading encoding-index-japanese v1.20141219.5 > Downloading encoding-index-tradchinese v1.20141219.5 > Downloading encoding-index-singlebyte v1.20141219.5 > Downloading encoding-index-korean v1.20141219.5 > Downloading encoding-index-simpchinese v1.20141219.5 > Downloading encoding_index_tests v0.1.4 > Downloading unicode-normalization v0.1.2 > Downloading unicode-bidi v0.2.3 > Downloading cfg-if v0.1.0 > Downloading backtrace-sys v0.1.3 > Downloading dbghelp-sys v0.2.0 > Downloading phf_shared v0.7.13 > Downloading debug_unreachable v0.0.6 > Downloading unreachable v0.0.2 > Downloading void v0.0.5 > Downloading phf_generator v0.7.13 > Downloading tenacious v0.2.0 > Downloading bincode v0.5.6 > Downloading byteorder v0.5.1 > Downloading uuid v0.2.0 > Downloading libz-sys v1.0.0 > Downloading gcc v0.3.26 > Downloading pkg-config v0.3.8 > Downloading offscreen_gl_context v0.1.3 > Downloading gl_generator v0.5.1 > Downloading xml-rs v0.3.0 > Downloading khronos_api v1.0.0 > Downloading bitflags v0.3.3 > Downloading x11 v2.3.0 > Downloading image v0.9.0 > Downloading time v0.1.34 > Downloading cssparser v0.5.5 > Downloading hyper v0.9.1 > Downloading servo-egl v0.2.1 > Downloading glx v0.1.2 > Downloading servo-skia v0.20130412.6 > Downloading servo-freetype-sys v2.4.11 > Downloading servo-glutin v0.4.16 > Downloading expat-sys v2.1.2 > Downloading servo-fontconfig v0.2.0 > Downloading shared_library v0.1.2 > Downloading x11-dl v2.4.0 > Downloading wayland-client v0.5.9 > Downloading wayland-window v0.2.3 > Downloading osmesa-sys v0.0.5 > Downloading wayland-kbd v0.3.5 > Downloading dylib v0.0.1 > Downloading wayland-sys v0.5.9 > Downloading crossbeam v0.1.6 > Downloading dlib v0.3.0 > Downloading libloading v0
Re: [dev] "Note On Webkit Versions"
Downloading png v0.4.3 Downloading jpeg-decoder v0.1.4 Downloading gif v0.8.0 Downloading flate2 v0.2.11 Downloading inflate v0.1.1 Downloading miniz-sys v0.1.7 Downloading rayon v0.3.1 Downloading lzw v0.10.0 Downloading color_quant v1.0.0 Downloading net2 v0.2.19 Downloading ws2_32-sys v0.2.0 Downloading xi-unicode v0.0.1 Downloading harfbuzz-sys v0.1.2 Downloading unicode-script v0.1.1 Downloading scoped_threadpool v0.1.7 Downloading regex v0.1.69 Downloading hbs-pow v0.2.0 Downloading serde_json v0.7.0 Downloading aho-corasick v0.5.1 Downloading memchr v0.1.10 Downloading utf8-ranges v0.1.3 Downloading thread_local v0.2.5 Downloading regex-syntax v0.3.1 Downloading thread-id v2.0.0 Downloading hbs-pow-sys v0.2.0 Downloading hbs-common-sys v0.2.0 Downloading hbs-builder v0.2.0 Downloading cmake v0.1.17 Downloading threadpool v1.0.0 Downloading mime_guess v1.6.0 Downloading immeta v0.3.2 Downloading phf v0.7.13 Downloading phf_codegen v0.7.13 Downloading arrayvec v0.3.16 Downloading nodrop v0.1.6 Downloading odds v0.2.12 Downloading phf_macros v0.7.13 Downloading xml5ever v0.1.2 Downloading ref_slice v0.1.0 Downloading html5ever v0.5.1 Downloading ref_filter_map v1.0.1 Downloading caseless v0.1.1 Downloading mac v0.0.2 Downloading tendril v0.2.1 Downloading utf-8 v0.6.0 Downloading futf v0.1.1 Downloading webdriver v0.9.0 On a 40MBit connection, it took 20 minutes. Still less deps than webkit, tho On Mon, May 2, 2016 at 10:37 AM, Sylvain BERTRAND wrote: > On Sun, May 01, 2016 at 01:23:54PM +0200, Sanel Zukan wrote: >> Mitt Green writes: >> >> but find me portable and usable C UI toolkit >> >> without tons of dependencies >> > >> > Tcl/Tk >> >> Hell yeah +1 > > Tk x11 widget toolkit needs Tcl scripting language... > > Not a lean set of C libs... :( > > -- > Sylvain > -- Aditya Goturu "The most dangerous phrase in the language is, We’ve always done it this way" - Grace Hopper Pubkey 4096R/727CEEED on pgp.mit.edu.
Re: [dev] Lag in when changing view to a OpenGL window
I don't think it can be gdm, as the gnome compositor is tied to their
window manager. Check if you have {compton, xcompmgr, cairo-compmgr,
unagi} running
On Fri, Dec 4, 2015 at 2:07 PM, Anders Straadt wrote:
> On Fri, Dec 4, 2015 at 1:38 AM, ACE wrote:
>> Do you have a composer enabled?
>>
>
> Forgive my ignorance, but I'm not sure how to check this. I run a
> recent Fedora with the default gdm display manager - could gdm or its
> x.org configuration enable a composer? I haven't done anything to
> enable it myself - I just added a minimal
> /usr/share/xsessions/dwm.desktop to make dwm available in gdm.
>
--
Aditya Goturu
"The most dangerous phrase in the language is, We’ve always done it
this way" - Grace Hopper
Re: [dev] [PATCH] Add libmill
On Thu, Nov 19, 2015 at 8:10 PM, Greg Reagle wrote: > On 11/19/2015 09:21 AM, Aditya Goturu wrote: >> libmill rocks. Patch attached > > Wow, libmill looks really good, based on the tutorial, if it works as > advertised. > I find I can think more clearly in C, so not needing go to do certain things nice. -- Aditya Goturu
[dev] [PATCH] Add libmill
libmill rocks. Patch attached -- Aditya Goturu From 0f40566cf816ee5bc9f851e46d7085451aca051d Mon Sep 17 00:00:00 2001 From: Aditya Goturu Date: Thu, 19 Nov 2015 19:47:10 +0530 Subject: [PATCH] Add libmill --- suckless.org/rocks.md | 1 + 1 file changed, 1 insertion(+) diff --git a/suckless.org/rocks.md b/suckless.org/rocks.md index 68c595d..6af297e 100644 --- a/suckless.org/rocks.md +++ b/suckless.org/rocks.md @@ -32,6 +32,7 @@ Miscellaneous * [libev](http://software.schmorp.de/pkg/libev.html) - high performance event-loop modeled after libevent but much smaller (dual licensed under 2-clause BSD and GPL) * [mdocml](http://mdocml.bsd.lv/) - The mandoc UNIX manpage compiler toolset * [morpheus](http://morpheus.2f30.org) - a statically linked musl based Linux distro +* [libmill](http://libmill.org/) - Go-style concurrency in implemented in C * [pjsip](http://www.pjsip.org/) - open source SIP stack (GPL) * [sdhcp](http://git.2f30.org/sdhcp/) - IPV4 DHCP client * [termbox](https://github.com/nsf/termbox) - simple ncurses-like library for creating TUIs -- 2.5.0
Re: [dev] surf release?
Why do we need to "appear busy". If people want to use better software, they will. We don't need to "appear busy" On Tue, Jun 2, 2015 at 12:42 AM, Greg Reagle wrote: > On Mon, Jun 1, 2015, at 02:36 PM, Eric Pruitt wrote: >> On Mon, Jun 01, 2015 at 02:18:01PM -0400, Greg Reagle wrote: >> > I don't know git well, just the basics, but why don't you use a git >> > commit id as the target for patching and packaging? As far as I >> > understand, a tag is just a "friendly" name for a commit id anyway. >> >> If $APPLICATION versions 4541b821941a65e9c220acec2ab7256d7b21d690 and up >> support features X, Y and Z, can you tell me whether or not version >> 02e09b181db9b55d93a43a943d49048a4aeb0364 also has those features? > > Based on only the git commit id, the answer is no, and traditional > version numbers are generally easier to compare; I see your point. But > with access to the git log, then the answer is yes. Also, each git > commit has a time-stamp (AFAIK). So the timestamp might be a way to > express the version number, for example 2015.06.01.15.00.29 > (year.month.day.hours.minutes.seconds in UTC), in a packaging system > that expects a traditional version number. These could be compared like > traditional version numbers. > >> This >> become even more of a nuisance when you only have immediate access to a >> compiled binary; I often build packages on one machine then distribute >> only the binaries. Using hashes for versioning means you can't >> $APPLICATION -V to easily figure out how old the binary is I'm using. > > I see your point. One way to resolve this problem is to have the -V > option display the git commit id and timestamp. > > Just to clarify, I'm not saying that using the git commit id and/or > timestamp is better than or as good as a traditional version number. > What I'm saying is that, given an upstream that doesn't tag versions > often enough for your liking, using the git commit id and/or timestamp > seems like a workable solution. > > -- > http://www.fastmail.com - Does exactly what it says on the tin > > -- Aditya Goturu Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway.
Re: [dev] [Idea] Using GitTorrent
I agree. Thats probably why the software sucks less in the first place. On Mon, Jun 1, 2015 at 8:55 PM, Martti Kühne wrote: > On Mon, Jun 1, 2015 at 5:16 PM, Ivan Tham wrote: >> Be confident for apps that suck less. Drop confident for apps that suck >> more. More importantly, **The Author Should Suck Less** >> >> I don't mean any insults. And if I did it, sorry. > > > I don't see suckless software shipped to people who wouldn't know why > to prefer this "confusing and pretty terrifying setup from the > 1980ies" (paraphrasing my former employer) over Ubuntu Unity. there's > no reason for most people in the world to ever use a terminal > emulator. > -- Aditya Goturu Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway.
Re: [dev] [Idea] Using GitTorrent
Sorry, messed up something about plain text. Here is my message: What are the exact reasons why github is harmful? I use github, but if there is anything wrong that I could not see till now, I would like to know it. Or do you mean the community of github is bad? On Sun, May 31, 2015 at 11:17 PM, Aditya Goturu wrote: > What are the exact reasons why github is harmful? I use github, but if > there is anything wrong that I could not see till now, I would like to know > it. Or do you mean the community of github is bad? > > On Sun, May 31, 2015 at 11:15 PM, Aditya Goturu wrote: >> What are the exact reasons why github is harmful? I use github, but if there >> is anything wrong that I could not see till now, I would like to know it. Or >> do you mean the community of github is bad? >> >> On Sun, May 31, 2015 at 9:41 PM, FRIGN wrote: >>> >>> On Sun, 31 May 2015 21:09:25 +0800 >>> Ivan Tham wrote: >>> >>> Hi Ivan, >>> >>> > I think that would make the projects in suckless more decentralized. >>> > I am just giving and idea but I still think the current system is >>> > better, using gittorrent may let the projects which are inspired by >>> > suckless work together in the suckless community. What do you think? >>> >>> GitHub is a deadly cancer infesting the very tissue of what makes up >>> quality software development. GitTorrent though is not affiliated >>> with it, and apart from the worries how to support "pull requests" and >>> other bullcrap, it's just a fundamental idea based on vanilla git. >>> >>> Now, regarding GitTorrent: Decentralizing is cool, but it's just too >>> complex to handle for most people. I've been into this area for some >>> time now, but I'm still not able to explain blockchains to a newbie, >>> which indicates that I'm still not intuitively handling this topic. >>> Same applies here: A central point, a server, can be a weak spot and >>> for large datasets, going decentral is very cool! >>> In the end though, same as with torrents (I only torrent the Debian >>> Live CDs/DVDs and other non copyright stuff of course (;), if a >>> torrent is not seeded, it will die. >>> Nowadays, if you want to keep a torrent service running as ideally as >>> on the paper (namely, people seeding back to a ratio of >1) you have >>> to force them into it by punishing those who just leech. >>> In the end, torrents which nobody downloads are less likely to be >>> seeded. And looking at suckless, we have numerous git-repos which just >>> are not that popular to begin with. >>> >>> The big problem I see is authentication, which has already been >>> discussed in the article. Using and developing blockchains is not >>> easy and this leads to errors which I'm personally not keen on handling. >>> >>> Cheers >>> >>> FRIGN >>> >>> -- >>> FRIGN >>> >> >> >> >> -- >> Aditya Goturu >> Never underestimate the bandwidth of a station wagon full of tapes hurtling >> down the highway. > > > > -- > Aditya Goturu > Never underestimate the bandwidth of a station wagon full of tapes > hurtling down the highway. -- Aditya Goturu Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway.
Re: [dev] [Idea] Using GitTorrent
What are the exact reasons why github is harmful? I use github, but if there is anything wrong that I could not see till now, I would like to know it. Or do you mean the community of github is bad? On Sun, May 31, 2015 at 11:15 PM, Aditya Goturu wrote: > What are the exact reasons why github is harmful? I use github, but if there > is anything wrong that I could not see till now, I would like to know it. Or > do you mean the community of github is bad? > > On Sun, May 31, 2015 at 9:41 PM, FRIGN wrote: >> >> On Sun, 31 May 2015 21:09:25 +0800 >> Ivan Tham wrote: >> >> Hi Ivan, >> >> > I think that would make the projects in suckless more decentralized. >> > I am just giving and idea but I still think the current system is >> > better, using gittorrent may let the projects which are inspired by >> > suckless work together in the suckless community. What do you think? >> >> GitHub is a deadly cancer infesting the very tissue of what makes up >> quality software development. GitTorrent though is not affiliated >> with it, and apart from the worries how to support "pull requests" and >> other bullcrap, it's just a fundamental idea based on vanilla git. >> >> Now, regarding GitTorrent: Decentralizing is cool, but it's just too >> complex to handle for most people. I've been into this area for some >> time now, but I'm still not able to explain blockchains to a newbie, >> which indicates that I'm still not intuitively handling this topic. >> Same applies here: A central point, a server, can be a weak spot and >> for large datasets, going decentral is very cool! >> In the end though, same as with torrents (I only torrent the Debian >> Live CDs/DVDs and other non copyright stuff of course (;), if a >> torrent is not seeded, it will die. >> Nowadays, if you want to keep a torrent service running as ideally as >> on the paper (namely, people seeding back to a ratio of >1) you have >> to force them into it by punishing those who just leech. >> In the end, torrents which nobody downloads are less likely to be >> seeded. And looking at suckless, we have numerous git-repos which just >> are not that popular to begin with. >> >> The big problem I see is authentication, which has already been >> discussed in the article. Using and developing blockchains is not >> easy and this leads to errors which I'm personally not keen on handling. >> >> Cheers >> >> FRIGN >> >> -- >> FRIGN >> > > > > -- > Aditya Goturu > Never underestimate the bandwidth of a station wagon full of tapes hurtling > down the highway. -- Aditya Goturu Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway.
