Beiträge, die mit Github getaggt sind
I was trying to make an #easy-share-option for Android/D* a while back but discovered that at the time, the only part of the #API which was implemented was the #OAuth2 / #OpenID login.
I did start to implement parts of the API to achieve my goal (sloppily, and in PHP ;) ) but got sidetracked into trying to find out what the state of the D* API was at the time (ie nonexistent) so let it slide.
Maybe I'll chuck the code up on my #github at some point. #diaspora #client #native
A security researcher has uncovered a ring of malicious GitHub accounts promoting over 300 backdoored Windows, Mac, and Linux applications and software libraries.
A security researcher has uncovered a ring of malicious GitHub accounts promoting over 300 backdoored Windows, Mac, and Linux applications and software libraries.
Better design for Github repository page
Article word count: 2256
HN Discussion: https://news.ycombinator.com/item?id=19276113
Posted by kirushik (karma: 298)
Post stats: Points: 122 - Comments: 71 - 2019-02-28T22:47:07Z
#HackerNews #github #page #redesigning #repository
Illustration by Yulia Prokopova
Github design is pretty good: it gets the job done, it’s clean, has consistent visual language, its design is calm and suitable for everyday use.
Given all that, there are still many areas that could be improved. Today we’ll take one interface—repository page—and look what UI problems it has and if we can fix them.
First problem: nested tabs
Let’s start with the biggest issue right away: information architecture. Take tabs. Currently there’re two levels of tabs, one nested under the other:
If you are a programmer, you might be surprised but other people normally don’t like hierarchies. Nested structures are hard to grasp, remember, navigate, and grouping is very often non-intuitive. Nested tabs are one of the worst UI patterns out there.
Then there’s a plain usability issue: let’s say I’m in Wiki and need to see Releases. What should I do? There’s no Releases tab visible, so I must figure out somehow that Releases are part of the Code (?). That makes almost no sense. Releases are as much part of the Code as Issues or Wiki are.
Solution here is to flatten all tabs into a single navigational control:
Organized that way, tabs are immediately accessible from anywhere in the repo. This is a big deal.
As a bonus, we also won quite a bit of vertical space without sacrificing anything! Vertical space is very important, it lets you see more content and get to it faster—all good things.
We still have one problem though: tabs don’t fit. We’re going to solve it by removing icons, but let me build up a case for that first.
Problem 2: Redundant icons
Icons are visual cues that help you scan the UI quickly. “Quickly” here means faster than reading text labels. If for some reason reading labels is still faster then icons aren’t working.
One example of icons misuse: if you put too many icons in a row and they are all different, they won’t work.
Prioritizing, or highlighting, something means deprioritizing everything else. You can’t highlight everything.
Another way to fail at icons: if you use obscure graphics, people will have to read labels anyways, so, again, not working.
Now let’s be honest: the domain of repository and project management is pretty abstract. No matter how good you are at design and how hard you try, you won’t come up with a great icon for a commit. Or a release. Or an issue. Or a license. A great icon is something other people know and understand. And for repositories, there’s simply none. I mean,
So Github tab icons are purely decorative. If you don’t believe me, look at what Github itself is doing. They dim icons:
That’s a sure sign that they, too, think it’s near impossible to figure out why backward clock means “Commit”. Github knows people will be looking at the labels anyways.
But even being decorative, they’re bad at it. I mean, Icon + Label + Counter make for a symmetric and weak composition:
By removing icons we:
1. free up a lot of horizontal space,
2. make design stronger, and
3. get rid of visual noize.
Win-win-win! Here’s the result, tabs without icons:
Test yourself, see if you can find Releases tab without an icon and if it was harder than before? It wasn’t, was it?
A note on this design: I am using the same limitations Github already uses: English language only, locked page width of 1020px. For different conditions, say, for the adaptive design we might want a different solution.
Another note: I had to remove Contributors tab (which was actually not a tab, but a sub-tab from Insights that was duplicated in Code for some reason) to accommodate for Settings tab. Don’t worry, we’ll get Contributors back later.
Problem 3: Vanity counters
This is the “vanity menu”:
The thing with vanity metrics is that there should be just one. One metrics is simple to understand and focus. Two or three split attention, making everything weaker.
Luckily for us, both watchers and forks perform poorly as metrics anyways. For watches, people tend not to watch too much. For forks, people tend to fork for no reason.
But stars work. They work because they have no other function but to represent vanity. So let’s keep stars and move them to the left to get more attention:
Problem 4: “Watch” button ambiguity
In the watch button we have a classic “button or status” UX dilemma. Buttons tell us what can be done but don’t say what the current status is. Status tells current state but it’s not clear what it would change to.
In Github case “Watch” has a button label but it doesn’t act as a button: clicking on it won’t make you watch the repo. It’s not a status either: if you see “Watch” it means you are not watching. Same for the other two states: they are neither buttons nor states.
The problem here is that a single button can’t be used to switch between three states. But dropdown can! Dropdowns are a well-established UI component that shows status and can be used to change it at the same time.
Funny, but Github is already using a dropdown! We just need to fix it to work as any other dropdown on Earth works: to show current status. Trivial fix, really:
Minor, but annoying: that checkmark is really hard to spot. Let’s highlight the whole row:
All together so far:
Uff, we’ve done a lot! If you need a little break, now would be a perfect time for it. Don’t worry, I’ll wait.
Back? Great! Let’s move on.
Problem 5: Repo description
This is the repository description:
The problem with it is: why is it located under the Code tab? It’s a description of the whole repository, not just its code, right?
To fix this let’s move it above the tabs, to the area that belongs to the whole repository:
It still needs a couple of touches.
First, font is neither big nor small (it’s 16px, standing between 18px repository name and 14px tabs). Let’s make it 14px so that there’re only two distinct font sizes. Also I’m sure there’s no need to render “https://” in the URL:
The second change is to move topics right next to the repository name. There’re usually just a few of those, so it seems wasteful to dedicate a whole line to them:
Look at us, winning more vertical space again!
Problem 6: Removing background color
Blue topics on blue background became harder to read. This is because they used to be on #FFF and now they’re on Github’s #FAFBFC “very light dirty blue”.
Let’s change tab’s background to #FFF too:
But why was that background there in the first place? What did it do?
My guess is Github had to add it because the structure of their menu layers was becoming too complex and they needed visual cues to help you “split” it in order to understand. The black top bar serves the same purpose: to separate. I mean, they were literally spending a good half of 768px screen at navigation alone.
When split into layers, at least you are not immediately scared by it. Without a background, it would be a mess.
But because we simplified the whole header so much and removed one intermediate layer, we don’t need that color coding anymore. Instead, we can enjoy fresh crisp white:
And look at all that free space! Finally, we can see some content in the top half of the screen too.
Problem 7: Description editing
A small touch. If you own the repository, you get to edit both its description and its topics:
First, the “Edit” button is badly misplaced — too far, easy to miss.
Second, separate edit button for topics is an artifact of topics system being developed at a different time, maybe by a different team. There’s really no need to have two separate buttons.
The solution? How many edit buttons do we need? I say none.
“But… Where did edit buttons go?” You might ask.
You see, the nature of description and topics is that it’s important to get people to fill them when they first create their repo. After that, people rarely change them at all.
When there is no description or no topics, we will show a button to add one:
And if description/topics are already filled, go to Settings to change them. Problem solved!
Problem 8: Files description
The traditional Windows File Explorer, together with macOS Finder, have established a simple pattern for file browsing: files on the left, details on the right.
Github decided to copy that pattern, but they put a very unexpected thing as details: a message from the last commit when that particular file was changed.
Why? I don’t know. Commits often touch files for completely arbitrary reasons, so the last commit tells you almost nothing. I can’t think of any case when somebody would need that particular information.
Maybe they wanted Github to be “about git” more than about traditional file browsing, and this was the only thing they could think of? That’s my speculation, anyway.
The problem with those details is not that such a huge area is filled with something so rarely useful. The problem is that it looks so much like file description it confuses me every time. “Tweak layout” is not a description of the “Docs” folder. “Need these debug tools too” for “Tools”—why should I care?
That means we can get rid of the descriptions without really losing anything:
Problem 9: Repository overview
When you get to the repository, the first page you see should not necessarily be Code. We better call it Overview—something to get a quick idea of what’s going on.
Now, the Github repository is more than just a list of files. It’s also about how those files change over time. What new features were added? Which bugs were fixed? Were there any new releases recently? All those are as important as the files themselves.
That’s why I suggest we add a list of recent commits to the Overview page next to files.
You can now see if a project is actively developed, maintained or abandoned, if an issue you care about was recently fixed, if a new version was recently published etc (notice tags and branches pills in commit list—I miss this feature on Commits tab SO MUCH).
What about that free space on the right? We can put useful stats there:
First, I added contributors. Github is all about people and collaboration, that’s why they put so much emphasis on Fork and PR buttons. Well, people are the face of that collaboration. They put their free time and energy to make that code happen. It’s only fair to see some of their faces.
Activity is a relatively new feature that hasn’t found its place on repository page yet—until now. Helps you see how much momentum the project has.
Language statistics was unfairly hidden away, now it’s front and foremost. I also added code size in lines of code — an obvious addition that Github still doesn’t have for some reason.
Altogether, in my opinion, the new Overview tab is more helpful in everyday use.
Problem 10: Contextualizing buttons
Both “Create new file”, “Upload files” and “Find files” all relate to files, so it will be reasonable to move them right next to the thing they operate on: Files.
Github always used to have clone URL directly on a page. That was pretty useful—when you needed to grab the code, no additional clicks were required.
Unfortunately, during one of the redesigns Github hid the clone URL behind a button. My guess is they did it because there was simply not enough space. But people kept looking for it so they had to paint the button green.
Well, after moving file buttons we have enough space to restore full-length Clone link:
I also unified all four ways to get the repo into a single control, because semantically they are pretty much the same: a way to get the code on your machine.
This is how Github used to look back in 2013:
And this is a screenshot from 2015:
Finally, this is how it looks today:
As you can see, the color scheme and main UI elements haven’t changed much since at least 2013. It’s not necessarily bad and mostly proves that the original design was good enough to stand the test of time.
But maybe it’s time to fresh it up a little? Get rid of gradients, dirty washed-out colors, unnecessary separators, add a little more air. Something like this:
If you feel disoriented, give it a minute. Once you are used to it, you might notice it’s actually easier on the eyes and a bit lighter.
Current Github design next to my proposal (click to open in a new window):
[IMG]We’ve added ~4 more files to the screen of the same vertical size, 6 last commits, 3 branches, 10 contributors’ faces, project activity AND expanded language stats WITHOUT losing any information.
If you know someone at Github, send them a link to this article. Maybe someone there will like my ideas and eventually get to implement them—who knows?
I’m Nikita. Here I write about programming and UI design Subscribe
I also create open-source stuff: Fira Code, AnyBar, DataScript and Rum. If you like what I do and want to get early access to my articles (along with other benefits), you should support me on Patreon.
HackerNewsBot debug: Calculated post rank: 105 - Loop: 89 - Rank min: 100 - Author rank: 41
Ein Softfork ist wohl eine neue Version des Projektes., die mit der alten Version kompatibel ist. Also in meinen Augen ein neues Release.
Ein Hardfork ist eine neue Version, die mit der alten Version nicht mehr kompatibel ist.
Hat man das in "Git Sprache" schon immer so ausgedrückt? Oder ist das nur wieder Business-Geschwurbel?
#Blockchain #Github #Fork #Kryptowährung
GitHub is where people build software. More than 31 million people use GitHub to discover, fork, and contribute to over 100 million projects.
HN Discussion: https://news.ycombinator.com/item?id=19182956
Posted by jordwalke (karma: 1420)
Post stats: Points: 143 - Comments: 60 - 2019-02-17T06:21:50Z
#HackerNews #but #faceswap #github #logged #public #repo #requires #user
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.
HackerNewsBot debug: Calculated post rank: 115 - Loop: 26 - Rank min: 100 - Author rank: 71
Have you ever wondered what it takes to build a rover like #NASA's #Curiosity #rover, part of the #Mars #Science #Laboratory #project?
Now students, hobbyists, and enthusiasts can learn about these skills....using plans and instructions from #JPL's #OpenSource #RoverProject.
#JPL #OpenSource #Rover #Project on #github
nasa-jpl/open-source-rover: A #buildityourself, 6-wheel #rover based on the rovers on #Mars! http://bit.ly/2DLJkHw
Uses #RaspberryPi #RPi #Camera #LCDpanel etc.
~~What the Fuck~~ 😀 WTF terminal dasboard
WTF is a personal information dashboard for your terminal, developed for those who spend most of their day in the command line.It allows you to monitor systems, services, and important information that you otherwise might keep browser tabs open for, the kinds of things you don’t always need visible, but do check in on every now and then.
Keep an eye on your OpsGenie schedules, Google Calendar, Git and GitHub repositories, and New Relic deployments.
See who’s away in BambooHR, which Jira tickets are assigned to you, and what time it is in Barcelona.
It even has weather. And clocks. And emoji.
- Download the stand-alone, compiled binary.
- Unzip the downloaded file.
- From the command line, cd into the newly-created /wtf directory.
- From the command line, run the app: ./wtf
... or install from source:
go get -u github.com/wtfutil/wtf cd $GOPATH/src/github.com/wtfutil/wtf make install make run
By default WTF looks in a ~/.config/wtf/ directory for a YAML file called config.yml. If the ~/.config/wtf/ directory doesn’t exist, WTF will create that directory on start-up, and then display instructions for creating a new configuration file.
In other words, WTF expects to have a YAML config file at: ~/.config/wtf/config.yml.
Example Configuration Files
A couple of example config files are provided in the _sample_configs/ directory of the Git repository.
To try out WTF quickly, copy simple_config.yml into ~/.config/wtf/ as config.yml and relaunch WTF. You should see the app launch and display the Security, Clocks and Status widgets onscreen.
Custom Configuration Files
To try out different configurations (or run multiple instances of WTF), you can pass the path to a config file via command line arguments on start-up.
To load a custom configuration file (ie: one that’s not ~/.config/wtf/config.yml), pass in the path to configuration file as a parameter on launch:
$> wtf --config=path/to/custom/config.yml
A number of top-level attributes can be set to customize your WTF install. See Attributes for details.
WTF uses the Grid layout system from tview to position widgets onscreen. It’s not immediately obvious how this works, so here’s an explanation:
Think of your terminal screen as a matrix of letter positions, say 100 chrs wide and 58 chrs tall.
Columns breaks up the width of the screen into chunks, each chunk a specified number of characters wide. use
[10, 10, 10, 10, 10, 10, 10, 10, 10, 10]
Ten columns that are ten characters wide
Rows break up the height of the screen into chunks, each chunk a specified number of characters tall. If we wanted to have five rows:
[10, 10, 10, 10, 18]
The co-ordinate system starts at top-left and defines how wide and tall a widget is. If we wanted to put a 2-col, 2-row widget in the bottom of the screen, we’d position it at:
top: 4 // top starts in the 4th row left: 9 // left starts in the 9th column height: 2 // span down rows 4 & 5 (18 characters in size, total) width: 2 // span across cols 9 & 10 (20 characters in size, total)
The heart of WTF is the modules. A module is a discreet unit of functionality that extracts data from some source and packages that data for display.
For example, the New Relic module uses New Relic’s API to retrieve a list of the latest deploys and packages that information as a list for display in the “New Relic” widget.
The Clocks module takes a list of timezones and packages that information as a list of city/time pairs for display in the “Clocks” widget.
The following top-level attributes are configurable in config.yml. See this example config file for more details.
wtf: colors: background: "red" border: focusable: "darkslateblue" focused: "orange" normal: "gray" grid: # How _wide_ the columns are, in terminal characters. In this case we have # six columns, each of which are 35 characters wide columns: [35, 35, 35, 35, 35, 35] # How _high_ the rows are, in terminal lines. In this case we have five rows # that support ten line of text, one of three lines, and one of four rows: [10, 10, 10, 10, 10, 3, 4] openFileUtil: open # the name of the utility to call to open files refreshInterval: 1 # the app refreshes once per second term: "xterm-256color"
#wtf #gnu #linux #console #terminal #util #tool #dashboard #soft #programm #go #git #github #command
instead of trying to find ways to do it inside the frederation/fediverse
Well, the #Fediverse is fractured into different parts, #Mastodon users (programmers) could then not communicated with #Diaspora users. #Github got kind of evil because of #Microsoft …
I knew the microsoft issue would come up ..
that's just kinda "different" battleground, although actually proves my centralized dependency point when it comes to: "let's discuss inside our realm!"
For me it's kinda strange that any coder of the federation-fediverse hasn't an account with any of the competetive but befriended projects.
Like to say:
For me as a surfer/user/testdriver and (dis)content creator it's basics to have an account on all the projects just out of curiosity and I think as a coder I would actively look out for what are doing the others to get more input, more ideas, widen my perception of the multiverse we create. So using the different platforms for the discussion is just a logical step for me that should naturally improve the whole system just by using it and knowing of each other.
If friendica is more kinda interconnecting platform it's reasonable to host the basic forum profiles there. If diaspora has a voting tool it's reasonable to use it so every one can "vote" with his diaspora account on surveys. If GNUsocial is (or mastodon, the one I haven't used yet) better for chit-chat about other aspects .. let's enjoy it and test it for that purpose.
That doesn't mean that if for specific important things a precise centralized tool fit's right now best (or is the established worst option for now) like it's the case for coding github or translations .. be it. And if coders say "for our needs we have to use discourse or other", I guess it's about specific needs to accomplish certain job .. perfect.
What I'm talking about is more in the direction of that I wonder if sometimes for coders every problem looks like the need for an app, a littel bit like when you have a hammer and every thumb looks like a nail you know. I get the impression that what the bigger picture → "the community" needs is implementation of "moderation tools" by moderators, something I guess is more about the realm of the work @Sean Tilley got when he came to the diaspora project long time ago.
To me it looks like that the "flaws" and imperfection of the federated fediverse needs some human man power to maintain the flux of conversation/information by doing the job of interlocutor, meaning man power driven dedicated forum pages and profiles on the different networks to keep the work/discussion going ..
not sure if this was more comprehensive @Hypolite Petovan (he/him) ??
This is nice, sure, but: If at all possible, please consider using other services – your local hackerspace might have a git server, or people around here might open theirs to you if you ask – or you could host it yourself, if you have the capability and resources. #git #github
HN Discussion: https://news.ycombinator.com/item?id=18847043
Posted by razer6 (karma: 561)
Post stats: Points: 214 - Comments: 85 - 2019-01-07T17:03:59Z
\#HackerNews #free #github #gives #now #private #repositories #unlimited #users
Due to a scheduling error, we published this story one day before the embargo lifted. This feature isn’t live yet, but Github will formally unveil it tomorrow. When that happens, we’ll update this post with a link to the official announcement.
GitHub is by far the most popular way to build and share software. That said, one weakness of the platform is that it limits who can create private repositories – that is, software projects that aren’t visible to the broader public, and are shared only with a handful of pre-defined collaborators – to paying users.
Fortunately, that’s no longer the case, as GitHub today announced it was giving users of its free plan access to unlimited private repositories. This is great news for GitHub’s users, but there is a caveat, of course.
Private repositories on free accounts are limited to three collaborators apiece. So, while this might work for a small project (like, for example, a team competing in a hackathon), it isn’t particularly well-suited for actual commercial usage.
That was probably a deliberate move from GitHub. There’s little risk of the company cannibalizing its existing paid users with this new free offering.
Until recently, developers who wanted to create private git repositories without opening their wallets were forced to use a rival service – most frequently BitBucket. Today’s news, obviously, isn’t great for Atlassian’s flagship code sharing platform, but it does mean that coders aren’t forced to use two disparate code management services for their private and public projects
I also wonder what ubiquitous private repositories will mean for Github’s culture of self-exhibition and sharing.
The absence of free private repositories essentially meant that people were forced to air their dirty laundry – their half-baked projects that never got finished and the clumsy spaghetti code they’d sooner forget. Now that people have the option to hide this behind a perfect shroud, will this harm GitHub’s culture of shameless openness and candidness?
Maybe. Time will tell.
Read next: Get your shit together in 2019 with these 7 free productivity tools
HackerNewsBot debug: Calculated post rank: 171 - Loop: 64 - Rank min: 100 - Author rank: 160
#NSA for world, peace, humanity 😀 ... and for #OpenSource (full list of GITprojects)
The last news: NSA to Release Their Reverse Engineering Framework #GHIDRA to Public at RSA (rsaconference.com)
Come Get Your Free NSA Reverse Engineering Tool!
NSA has developed a software reverse engineering framework known as GHIDRA, which will be demonstrated for the first time at RSAC 2019. An interactive GUI capability enables reverse engineers to leverage an integrated set of features that run on a variety of platforms including Windows, Mac OS and LINUX and supports a variety of processor instruction sets. The GHIDRA platform includes all the features expected in high-end commercial tools, with new and expanded functionality NSA uniquely developed, and will be released for free public use at RSA.
March 4 – 8
Moscone Center, San Francisco
Speaker: Robert Joyce Senior Advisor, National Security Agency
Tuesday, Mar 05 | 03:40 p.m. - 04:30 p.m.
https://code.nsa.gov/ (full list)
P.S. As for me... SELinux is wonderful! 😀
#nsa #gnu #linux #windows #macos #java #selinux #code #coding #software #git #github #opensource #freesoftware #usa
Inhaltswarnung: I do confess: I used to be a user, and [i]just[/i] a user of social media. Hubzilla with all its options can be quite intimidating, therefore I didn't dive into all the details and opportunities like I possibly should have. During the last 2-3 months, com
Diaspora doesn't federate with anything, the other platforms federate with it/them[?]...
(Mike Macgirvin, as seen in some comment thread recently. I forgot where exactly.)
So, I've seen this problem's description from my d* stream only because and therefore after the issue had been solved, but I wasn't sure about that at this point. It got solved by helpful co-Hubzillians in a comment thread of another help-seeking post, where noone complained and noone blamed this user for not knowing. The topic itself was intriguing for me. For that reason I wrote a (hopefully not too) comprehensive comment to help out with my findings. I wrote all that from my d* pod, just as a reminder.
Sure enough, I didn't see from my limited d* perspective what other people, coming from Friendica or Hubzilla, added to the comment thread. And most probably vice versa. Then I tried to double-check whether I might trick broken federation by clicking on the "permalink" symbol, just to find yet another issue: Long-version Hubzilla permalinks are broken on diaspora* and it's a known bug. Let me explain and come back to my initial topic afterwards:
In case you (as in: d* users) didn't know: By clicking on the little chain lock link symbol next to the "date posted" in a d* stream one can open the long-format permalink to a post that has made its way to your pod and stream. For posts created on Hubzilla, this will result in a "404 - not found", sported by the/your d* pod, while the short version (from clicking on the date/time combo itself) works, but only on this very d* pod, e.g.
What I learned so far:
- one could use the long permalink version (with the so-called GUID) on every single d* pod as long as the first section corresponds with the pod they're on, i.e. just replace
https://dspr.io/by your own pod-URL
- long permalinks will work as a public link even if the reader is not logged into any hub (as long as the post was public. Maybe even if not, haven't tested.)
- short "perma"link will only work on this very pod internally.
https://dspr.io/posts/xxxx5xxxx10xxx15xxx20xxx25xxxx31diaspora*: 31 digits
https://dspr.io/posts/xxxx5xx8-xxx4-xxx4-xxx4-xxxx5xxxxx12Friendica: 5 groups, with a total of 36 digits/characters
https://dspr.io/posts/xxxx5xxxx10xxx15xxx20xxx25xxx30xxx35xxx40xxx45xxx50xxx55xxx60xxx@[subdomain].[domain].[tld]Hubzilla: 63 digits plus user ID
Now we're slowly approaching the main topic again. Not only does Hz sport communities, their developer team is incredibly responsive as well. I've seen Mike Macgirvin join discussions on literally every Zot-related platform I am aware of, always helpful, always outcome-oriented. I do not know (as in: have seen their profiles) of each single team member, but Mike's presence is remarkable, and just the opposite of a statement he made over at gnusocial:
Fediverse developers can be an incredibly toxic mob. I've found they are often more polite if you talk to them using their own software.
Should I file an issue then? Sure, if it's helpful..? I searched for "perma" over at Hz's issue tracker and found this: https://framagit.org/hubzilla/core/issues/1214
Hubzilla, Diaspora & permalink
[...]The Hubzilla permalinks generate an 404 error from a Diaspora account[...]
Exactly what I was looking for! ... But wait, that issue is still open, although it's 6 months old..? Oh well. But wait, there's more, this is not the end of my story, not by far --- thank you for your patience, by the way, please bear with me 😀
And again, I'd like to make this point clear: the following is absolutely not meant to be offensive, nor would I want to point out a single person. Every developer of whatever fediverse platform has my honest respect, not only for working on their project(s) in their spare time. I wish I could participate more, I wish I had the knowledge to do so.
Jun 8th, 2018 - The person who filed the issue to the Hz issue tracker did so as well on diaspora*'s GitHub repository, As you can read from the framagit comment, that was a duplicate. He/she got redirected to a slightly older issue from May 15th, 2018 which you can find here. A common procedure. That timeline reads as follows:
- May 15th - initial comment with description and suggestions.
- same day - 6 comments later the 3 participants (author plus 2 project maintainers) agree on a way how it is possible to fix it. They have immediately and open-heartedly stated that GUID permalinks from Hz don't work, but used to do so. Some background info is shared, including remarks about coding philosophies and guidelines.
- Jun 8th - nothing visible has happened so far. The duplicate reference is documented.
- Sep 4th - a team member adds labels: "bug" (for the first time) and "weird" (I love that one!). 3 1/2 months have passed.
- Oct 4th - Some change has been merged, declaredly having fixed the issue. Issue is closed, because the fix has been approved.
- Oct 5th thru Oct 8th - this is where it gets confusing for me, but interesting as well: A bump, some pull requests and, if you're still not tired of following all the cross referencing links, the attempt of a willing-to-help person to "spam" the maintainers with his solution for organizing pull requests. He gets answered elaborately. Appropriately? Please make up your own mind and think of what Mike said.
- Oct 5th - somehow something didn't work, the ticket is open again, still not fixed.
- Dec 31st (today) - Another 2 1/2 months passed. The issue is 7 1/2 months old, still open although seemingly quite easy to fix.
Did GUID permalinks ever work for Hubzilla? --- The statements differ. If they did, at some point some d* developer has broken it. If not, why would this platform need to produce as many links prone to 404 status as there are posts on a pod? For web crawlers, this is just a nightmare and it takes no wonder why decentralized networks technically only(!), as seen from a search engine's view have mendable reputation.
Why did it take over 3 months to label the issue a "(weird) bug"? --- Was there no structure to the issue list before? Of course, labels alone won't make for a well-organized work flow, there are many different and efficient ways to approach a growing list of todos and priorities. Well, someone finally felt the need of labelling it.
The issue had been worked on, got marked fixed and closed. Why the withdrawal? --- This is where it gets opaque, but maybe it's just me not reading the documentation thoroughly enough. I hope it's legit to apprehend that there is a massive problem concerning capacity, availability and of course time.
A link that isn't producible is a link not shareable... --- which makes d* sort of a "closed" network, doesn't it? I didn't join MeWe for that reason (amongst others).
From what I have learned about development-related people over at diaspora*, they're focused but open-minded, they know how they're doing things and why. Besides a whole lot of time they put pride in their work. Unfortunately it looks like there are not enough of them..?
This means for me as a user that I most probably can or should not count on major improvements in functionality, at least not very soon. There are several more issues I personally see in the d* concept, but it took me a while to find out. To put these in here as well would be overkill. Diaspora* really shines when it comes to simplicity but ease of use is not my main priority.
My verdict: Hubzilla has --by far-- much more potential than diaspora*. The team behind Hz appears to be very present, numerically adequate and striving for constant improvement. With all the extra features Hz has built-in in contrast to d* it's the one platform I can think of self-hosting it, d* won't offer incentive enough to do so right now.
If you (like me) want diaspora* to become an even better platform, the platform needs your help.
If you (unlike me) are a skilled Ruby, JSON, you name it wizard, please consider participating, the platform deserves your support.
And if you really have read this post completely: thank you! I hope I didn't stress your patience too much -- it was your decision to spend your time this way, I've warned you! 😉 This was very probably my last post for 2018. I would appreciate your feedback nevertheless.
Happy New Year!
#hubzilla #diaspora #github #framagit #issue #issuetracker #bug
when i try to update my friendica node with
git pullan error message appears:
$ git pull *** Please tell me who you are. Run git config --global user.email "email@example.com" git config --global user.name "Your Name" to set your account's default identity. Omit --global to set the identity only in this repository. fatal: empty ident name (for < ... >) not allowed
Did anybody else see this error message? This message only appears on the friendica core repository, update the addons works fine.
#friendica #git #github
Vous pouvez retrouver la complète des changements sur #github : https://github.com/Chocobozzz/PeerTube/releases/tag/v1.1.0-rc.1
Merci à tous les contributeurs qui ont participé !